Подскажите как маршрутизируется трафик для впн?

Вы показали только main таблицу маршрутизации, в команде ip таблица маршрутизации указывается опцией table.

У вас там есть таблица маршрутизации 52312, в которую попадают все пакеты, не помеченые меткой 0xcc58, и не нашедшие маршрута по предудыщему правилу (то есть те пакеты, которые пошли бы по default маршруту таблицы main).

Насколько я помню, эту таблицу создаёт wireguard, меткой 0xcc58 он помечает свои udp или какие там транспортные пакеты, а все остальные заворачивает в тунель.

Из вашей темы непонятно, вам доступ в интерент через тунель нужен, или в тунель только определёные ip-адреса, а досутуп в инет без тунеля?

Включен ufw

Зачем на компе в локальной сети нужен firewall?

Фаервол нужен потому, что тунель ведет на впн сервер мой, а впс на котором он сидит могут и ломануть, он торчит голым задом в интернет…правда закрыто там все, но просто на всякий случай, пока я все настраиваю и разбираюсь. Мне нужно что бы через тоннель ходило все, для начала, что бы работало. Сложности потом. В итоге я хочу два впн, один рабочий и в него что бы текло то, что идет на рабочий домен в локалке, а второй «все остальное». Так что разобраться сначала с простым бы, а потом понять как сделать не простое. Я начитался про маршрутизацию, но пока плохо понимаю. Вот вывод всех таблиц:

при подключенном впн

ip route show table all
default dev wg0 table 52312 proto static scope link metric 50 
default via 192.168.1.1 dev wlp4s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp4s0 scope link metric 1000 
192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.163 metric 600 
192.168.32.0/20 dev docker0 proto kernel scope link src 192.168.32.1 linkdown 
local 10.2.53.3 dev wg0 table local proto kernel scope host src 10.2.53.3 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.1.163 dev wlp4s0 table local proto kernel scope host src 192.168.1.163 
broadcast 192.168.1.255 dev wlp4s0 table local proto kernel scope link src 192.168.1.163 
local 192.168.32.1 dev docker0 table local proto kernel scope host src 192.168.32.1 
broadcast 192.168.47.255 dev docker0 table local proto kernel scope link src 192.168.32.1 linkdown 
default dev wg0 table 52312 proto static metric 50 pref medium
::1 dev lo proto kernel metric 256 pref medium
fc10:253::3 dev wg0 proto kernel metric 50 pref medium
fe80::/64 dev docker0 proto kernel metric 256 linkdown pref medium
fe80::/64 dev wlp4s0 proto kernel metric 1024 pref medium
fe80::/64 dev wg0 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fc10:253::3 dev wg0 table local proto kernel metric 0 pref medium
local fe80::42:60ff:fef6:2bf8 dev docker0 table local proto kernel metric 0 pref medium
local fe80::611a:6600:5581:de61 dev wg0 table local proto kernel metric 0 pref medium
local fe80::a5f8:72b5:59f6:ba37 dev wlp4s0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev docker0 table local proto kernel metric 256 linkdown pref medium
multicast ff00::/8 dev eno1 table local proto kernel metric 256 linkdown pref medium
multicast ff00::/8 dev wlp4s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wg0 table local proto kernel metric 256 pref medium

а это без него

ip route show table all
default via 192.168.1.1 dev wlp4s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp4s0 scope link metric 1000 
192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.163 metric 600 
192.168.32.0/20 dev docker0 proto kernel scope link src 192.168.32.1 linkdown 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.1.163 dev wlp4s0 table local proto kernel scope host src 192.168.1.163 
broadcast 192.168.1.255 dev wlp4s0 table local proto kernel scope link src 192.168.1.163 
local 192.168.32.1 dev docker0 table local proto kernel scope host src 192.168.32.1 
broadcast 192.168.47.255 dev docker0 table local proto kernel scope link src 192.168.32.1 linkdown 
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 linkdown pref medium
fe80::/64 dev wlp4s0 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::42:60ff:fef6:2bf8 dev docker0 table local proto kernel metric 0 pref medium
local fe80::a5f8:72b5:59f6:ba37 dev wlp4s0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev docker0 table local proto kernel metric 256 linkdown pref medium
multicast ff00::/8 dev eno1 table local proto kernel metric 256 linkdown pref medium
multicast ff00::/8 dev wlp4s0 table local proto kernel metric 256 pref medium

Вот конкретно та

ip route show table 52312
default dev wg0 proto static scope link metric 50 

Я нашел описание того как это работает. Вот это 31038: from all lookup main suppress_prefixlength 0 31039: not from all fwmark 0xcc58 lookup 52312

означает, что когда в таблице майн пакет попал в дефолт правило, оно передается в таблицу 52312, но в эту таблицу попадает только не трафик самого вайргарда, который метится. В итоге в этой таблице работает. default dev wg0 proto static scope link metric 50

То есть вроде бы все верно по маршрутам, но не пашет. Вот я и не понимаю, может пакеты самого вайргарда, которые он метит надо как то через физический интерфейс слать специально?

оказывается дело судя по всему не в маршруте, а в DNS. Часть сайтов работает! Надо копаться с тем какой сервер используется.

Опять непонятно. Значит пакеты ходят. На впн серваке у меня заодно стоит и pi.hole dns с резкой рекламы.

resolvectl query pi.hole
pi.hole: 10.2.53.1                             -- link: wg0
         fc10:253::1                           -- link: wg0

-- Information acquired via protocol DNS in 31.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

он опознается но не работает ни ping 10.2.53.1, ни ping pi.hole

Судя по всему дело в этом правиле local 10.2.53.3 dev wg0 table local proto kernel scope host src 10.2.53.3

С проблемой пакетов до pi.hole, либо я что то не понял. Но почему сайты то частично работают и днс, неясно.

Добавил маршрут

sudo ip route add 10.2.51.0/24 dev wg0

пинг до ping 10.2.53.1 и ping pi.hole заработал. Дальше пока неясно.

У меня в настройках wireguard в NetworkManager такое

ipv4.dns:                               10.2.53.1
ipv4.dns-search:                        ~
IP4.ADDRESS[1]:                         10.2.53.3/32
IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 50, table=52312
IP4.ROUTE[2]:                           dst = 10.2.51.0/24, nh = 0.0.0.0, mt = 0
IP4.DNS[1]:                             10.2.53.1

И оно раньше работало, непонятно почему сейчас вдруг сломалось. Может он не понимает, что pi.hole это DNS сервер?

Может это роутер прислал днс сервер, который перетер днс сервер, который выставил wireguard? Не знаю где это смотреть.

Ты троллируешь или реально не понимаешь?

Непонятно, вот этот адрес пашет https://wiki.archlinux.org/title/Avahi этот нет https://www.opennet.ru/

На телефоне пашут оба, впн один, днс сервер один pi.hole, которая рядом с впд установлена. Но до самой pi.hole не зайти, хотя пинг идет, но почему то по ipv6

ping pi.hole
PING pi.hole(pi.hole (fc10:253::1)) 56 data bytes

не понимаю, я не тролю в сети.

пинг адреса pi.hole (она в впн локалке как бы) идет

ping 10.2.53.1
PING 10.2.53.1 (10.2.53.1) 56(84) bytes of data.
64 bytes from 10.2.53.1: icmp_seq=1 ttl=64 time=28.0 ms

После перезагрузки даже без sudo ip route add 10.2.51.0/24 dev wg0 пинг до пихоля работает. Я вроде не сохранял правила нигде и в таблицах его не вижу, а работает. Мистика.

вот трейсроут без впн

traceroute filmix.ac
traceroute to filmix.ac (31.222.238.22), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  1.716 ms  1.586 ms  1.495 ms
 2  192.168.0.1 (192.168.0.1)  3.746 ms  3.727 ms  4.320 ms
 3  10.10.10.1 (10.10.10.1)  15.080 ms  15.064 ms  15.051 ms
 4  * * *
 5  sk-bts04a-rd1-ae-4-0.aorta.net (84.116.135.161)  43.728 ms  43.711 ms  43.698 ms
 6  at-vie05e-ri1-ae-6-0.aorta.net (213.46.160.89)  43.681 ms  44.482 ms  44.452 ms
 7  nl-ams17b-rc1-lag-23-0.aorta.net (84.116.136.150)  44.462 ms  39.920 ms  39.896 ms
 8  * * *
 9  213.46.186.26 (213.46.186.26)  44.089 ms 213.46.186.27 (213.46.186.27)  38.987 ms  41.468 ms
10  185.8.179.38 (185.8.179.38)  41.446 ms  41.424 ms  40.934 ms
11  5.178.67.49 (5.178.67.49)  40.860 ms  40.840 ms  39.734 ms
12  185.15.209.25 (185.15.209.25)  39.683 ms  38.020 ms  37.685 ms
13  * * *
14  mail.filmix.me (31.222.238.22)  37.330 ms  41.950 ms  41.924 ms

а вот с впн

 1  pi.hole (10.2.53.1)  30.404 ms  30.367 ms  35.399 ms
 2  * * *
 3  10.82.4.42 (10.82.4.42)  36.103 ms 10.82.4.38 (10.82.4.38)  39.968 ms  39.909 ms
 4  138.197.250.112 (138.197.250.112)  35.321 ms 138.197.250.120 (138.197.250.120)  35.286 ms 138.197.250.90 (138.197.250.90)  35.243 ms
 5  138.197.250.94 (138.197.250.94)  35.236 ms 138.197.250.80 (138.197.250.80)  41.283 ms 138.197.250.76 (138.197.250.76)  35.216 ms
 6  ams-ix.retn.net (80.249.209.216)  35.722 ms  56.435 ms  38.344 ms
 7  ae0-3.RT.SRV.DRO.NL.retn.net (87.245.232.44)  38.235 ms  38.211 ms  38.196 ms
 8  GW-MIRhosting.retn.net (87.245.211.9)  54.066 ms  53.995 ms  53.899 ms
 9  185.15.209.25 (185.15.209.25)  50.837 ms  50.831 ms  50.816 ms
10  * * *
11  mail.filmix.me (31.222.238.22)  49.514 ms  49.490 ms  49.472 ms

Но с впн в браузере тишина.

Вы же, вроде, диагностировали, что проблема в DNS? По ip-адресам браузер что-то грузит, допустим 1.1.1.1?

Если у вас на openwrt поднят dnsmasq, то попробуйте переключить DNS на него, посмотреть заработает браузер.

Проблема с настойкой pi.hole это отдельная тема, особенно если вам ещё и ipv6 хочется.

Браузер 1.1.1.1 не открывает. Мистика в том, что через тот-же роутер подключен телефон и там тоже настроен тот же впн с тем же pi.hole. И сам пихол доступен в браузере по http://pi.hole и все пашет. С компа же я сделал подключение как через wg-quick, так и через nmcli, оба впн включают, но начинаются вышеописанные проблемы. При этом http://pi.hole в браузере не доступен, что самое странное. На самом openwrt роутере я ничего не поднимал, просто прошил прошивку и после этого настроил вайфай, разве что там по умолчанию что то есть, не знаю.

Зачем столько лишней информации? Вы уже третий раз пишете, что телефон работает через впн. Это уже реально похоже на троллинг.

оба впн включают,

Зачем вы делаете два впн подключения, если даже одно не работает?

При подключенном vpn в одном терминале запускаете:

(от root)# tcpdump -i wg0 -n -nn host 193.166.3.2

В другом

telnet 193.166.3.2 80

Если у вас будет выведено:

Trying 193.166.3.2...
Connected to 193.166.3.2.
Escape character is '^]'.

Значит tcp-пакеты ходят. Если telnet не выводи «Connected», значит tcp-соединение не устанавливается. Посмотрите вывод:

dmesg -T | grep wg0

Если telnet устанавливает соединение, пробуете в браузере http:\\193.166.3.2 и должна отобразится простая web-страница NIC.FUNET.FI. Но если у вас в браузере https Everywhere или ещё какие неадекватные расширения, то не знаю. Попробуйте по https это же адрес. Если страница не открывается, смотрите что в tcpdump, есть ли там вобще от вас к 193.166.3.2, правильный ли у них src-адрес (адрес на wg-интерфейсе) и есть ли ответные пакеты.

Там в выводе tcpdump всё просто, сначала src-ip адрес.порт, потом > и dst-ip адрес.порт .

http:\\193.166.3.2 и должна отобразится простая web-страница

slash, а не backslash.

Вот дамп

sudo tcpdump -i wg0 -n -nn host 193.166.3.2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
19:18:06.481560 IP 10.2.53.3.42022 > 193.166.3.2.80: Flags [S], seq 829631912, win 64952, options [mss 1412,sackOK,TS val 4245736945 ecr 0,nop,wscale 7], length 0
19:18:09.069705 IP 10.2.53.3.32884 > 193.166.3.2.80: Flags [S], seq 7784689, win 64952, options [mss 1412,sackOK,TS val 4245739533 ecr 0,nop,wscale 7], length 0
19:18:10.129548 IP 10.2.53.3.32884 > 193.166.3.2.80: Flags [S], seq 7784689, win 64952, options [mss 1412,sackOK,TS val 4245740593 ecr 0,nop,wscale 7], length 0

При этом телнет

telnet 193.166.3.2 80
Trying 193.166.3.2...

Коннекта не дает и браузер страницу не открывает.

В выводе этой команды:

dmesg -T | grep wg0

нет строк «Packet has unallowed src IP»?

В вашем tcpdump'е вобще нет ответов от 193.166.3.2, но пакеты в тунель уходят. Уходя, вроде, с правильным src-ip адресом. То есть тут маршрутизация как надо отрабатывает. Так что нужно «идти» дальше и смотреть что на VPN-сервере.

На VPN-сервере tcpdump запустить можете? Аналогично на этот ip-адрес (host), на интерфейсе (-i), который в инет смотрит.

Мне удобнее нажимать обратный слеш, клавиша рядом с Enter :) Хромому, года с 2010 пофиг, Мозиле, ещё раньше чем хромому стало пофиг. Пишут что и Сафари пофиг, и, что вобще можно писать: http:/\193.166.3.2

https://zzz.buzz/2017/09/19/forward-and-backslashes-in-urls/

В вебе клали все болт на стандарты. Как ламер написал, так и должно быть :) ЕМНИП, Мозила лет 5 выпендривалась, заявляла что мы только стандарт понимаем, кривые страницы не показываем. Но потом прогнулись и стали показывать страницы, которые до этого только в ie4/ie5 отображались...

От про «осла» не надо! Это «дизигеры» очнулись и стали переделывать свои поделия. Но «осел онлу» ещё наверное можно встретить... наверное... :)

в

dmesg -T | grep wg0

таких строк нет. Что касается tcpdump, то судя по всему это отличное средство диагностики, попробую попозже. Я до сих пор не знал как определить путь пакета полностью куда идет…кроме шарка но его откладывал как последнее средство. tcpdump казался какой-то ерундовой утилитой, которая не нужна. Изучу. Решил не использовать готовую сборку пихоля, а поднять все сам. Если там такие же проблемы будут, то снова вернусь к вам с вопросами. Пихоль мне надо перенести на впс без лимита на трафик все равно. Спасибо большое.

Kali набеги сменились wireguard набегами. Чё в лесу сдохло?

Зачем на компе в локальной сети нужен firewall?

За тем что NAT не фаерволл

Волга впадает в Каспийское море. Лошади кушают овес и сено.

У меня на домашнем компе слушает только sshd и всё, от чего в этом случае защищает firewall при взломе шлюза в инет?

У меня

Так то у тебя.

от чего в этом случае защищает firewall при взломе шлюза в инет?

Так и ломать ничего не надо. v6 уже не такая редкость. И вообще…

Kali набеги сменились wireguard набегами. Чё в лесу сдохло?

Вышел видос настраиваем wireguard на kali super security mega hack

То есть в контекст вы не умеете. Читаете вопрос и сразу отвечаете по первому совпадению в методичке. Вопрос был задан ТСу, зачем ему файервол на локальном компе, нужен ли он ему постоянно или он может его отключить на время, что бы убедиться, что его проблема не связана с кривыми настройками и т.д. Никакого интернета по ipv6 у него нет.

Ну, а nat slipstreaming — это какой-то бред. Сначала ставим непойми что в качестве шлюза в инет, а потом защищаем локальный компьютер файерволом, так по вашей методичке? Вместо настройки файервола на маршрутизаторе, заявляем, что «NAT не фаерволл» и всё тут, файервол — это только ufw на локальном компе?

Вы вместо ответа на вопрос о нужности файервола на локальном компе при взломаном маршрутизаторе ответили, что у большинства там и так дыра. Я ещё раз спрашиваю, смысл защищать файерволом самое устойчивое (компьютер с линуксом) устройство в домашней сети, в которой могут быть NAS, ip-камеры, игровой комп с виндой, планшеты с необновляемым андройдом и т.д.?

Ты разбираешь на частности общий принцип (вектор атаки) обеспечения безопастности. Это не промышленный и некоструктивный посыл. Да, ты прав в 99,(9)% случаев, но это количественное, а не качественное выоажение проблемы. NAT is not firewall абсолютно верное утвкрждение, т.к. атакующий, имеющий доступ к WAN маршрутизатора неиллюзорно может гулять в твоем LAN.

NAT is not firewall абсолютно верное

Как и куча других утверждений учителя словесности.

Но мне непонятно почему все считатю, что маршрутизатор/шлюз в инет это только NAT? На нормальном маршрутизаторе можно настроить firewall ведь?

WAN маршрутизатора неиллюзорно может гулять в твоем LAN

Это какая-то сдача всех позиций, сначала ставим маршрутизатор с дырявым NAT, разрешаем браузеру делать что угодно, а потом пытаемся защиться комп от входящих соединений. Я понимаю, локальным файерволом ограничивали бы браузер, но про это особо не пишут.

Ну и отдельно у меня вызывает раздражение ufw. Запускаешь ufw status, всё красиво. Но это иллюзия, ведь есть ″before.rules″ куда может быть напихано что угодно. Такая же иллюзия как блокировка root в Ubuntu, где sudo без пароля.

В итоге когда сам поднял тоже сначала не работало. Но выяснилось в итоге, что через маршрут по умолчанию доступна сеть с такими же адресами как были мной выбраны для впн, только провайдерская. Когда выбрал другую сетку все завелось.