LINUX.ORG.RU
Форум — Admin  

Нет интернета через OpenVPN

 


0

1

Имеется сервер OpenVPN с таким конфигом - http://pastebin.com/nF5gGu8N

Правила iptables такие - http://pastebin.com/rVGyyLgq

Перенаправление трафика разрешено:

# cat /proc/sys/net/ipv4/ip_forward
1

На сервере также имеется dnsmasq, который занимается только DNS, без DHCP.

На сервере интернет есть и отлично работает - можно сделать хоть ping 8.8.8.8, хоть ping google.com.

Подключается клиент. Единственная команда, которая выполнится успешно - ping 10.8.0.1, все остальные варианты (хоть по IP, хоть по DNS-имени) оканчиваются неудачно. Сервер полностью доступен через VPN (можно, например, зайти на него по SSH), однако раздавать интернет упорно не хочет. Да, DNS через VPN работает (засчёт того, что в OpenVPN прописан адрес сервера, как источника DNS)

В чём может быть дело?

Вот свойства интерфейса VPN на сервере:

# ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 1068  bytes 77571 (75.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 456  bytes 74973 (73.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

А вот на клиенте:

# ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.2  netmask 255.255.255.0  destination 10.8.0.2
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 391  bytes 65376 (63.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1091  bytes 74433 (72.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
★★★★★

Последнее исправление: KivApple (всего исправлений: 1)
← Правило для iptables на prerouting
zfs cpu →

Ответ на: комментарий от anonymous 
$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        0.0.0.0         UG    50     0        0 tun0
0.0.0.0         10.0.0.1        0.0.0.0         UG    100    0        0 eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     100    0        0 eth1
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.8.0.0        0.0.0.0         255.255.255.0   U     50     0        0 tun0
XXX.XXX.XXX.XXX  10.0.0.1        255.255.255.255 UGH   100    0        0 eth1

Где ХХХ.ХХХ.ХХХ.ХХХ - адрес сервера. Надо также заметить, что у меня интернет через 4G-модем Yota, который выдаёт моему компьютеру адрес 10.0.0.10, а сам является шлюзом по адресу 10.0.0.1.

Без VPN вот такие параметры:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    100    0        0 eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     100    0        0 eth1
$ ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.10  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::fa35:ddff:fe3a:cea1  prefixlen 64  scopeid 0x20<link>
        ether f8:35:dd:3a:ce:a1  txqueuelen 1000  (Ethernet)
        RX packets 23105  bytes 18762543 (17.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25193  bytes 3986988 (3.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)

Имеется сервер OpenVPN с таким конфигом -

ну хотя бы отгрипал бы комменты. А то не думаю что кому то удобно читать.

snaf ★★★★★
()
Последнее исправление: snaf (всего исправлений: 2)

Для начала запускаете на клиенте ″traceroute -I -n″ на любой адрес в инете и убеждаетесь, что в выводе первым идёт openvpn сервер.

Потом запускаете на клиенте ″ping″ на этот адрес, а на сервере ″tcpdump″ на внешнем интерфейсе (eth0 вроде как) на перехват icmp-пакетов и смотрите, уходят ли пинги от клиента наружу.

mky ★★★★★
()
Ответ на: комментарий от mky

Выполняю на клиенте traceroute:

$ sudo traceroute -I -n 8.8.8.8
[sudo] пароль для kiv: 
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.8.0.1  123.839 ms  124.280 ms  125.339 ms
 2  * * *
 3  * * *
 4  * * *
... и так далее ...

Вот такое происходит на сервере, если клиент пытается попинговать гугл, однако при этом ответов клиент VPN не получает.

# tcpdump -i eth0 "ip proto \icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:47:36.397684 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 42, length 64
22:47:36.434446 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 42, length 64
22:47:37.397668 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 43, length 64
22:47:37.434687 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 43, length 64
22:47:38.397511 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 44, length 64
22:47:38.434267 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 44, length 64
22:47:39.389974 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 45, length 64
22:47:39.426741 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 45, length 64
22:47:40.389692 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 46, length 64
22:47:40.426480 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 46, length 64
22:47:41.398640 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 47, length 64
22:47:41.435540 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 47, length 64
22:47:42.389688 IP my-server > google-public-dns-a.google.com: ICMP echo request, id 7262, seq 48, length 64
22:47:42.426497 IP google-public-dns-a.google.com > my-server: ICMP echo reply, id 7262, seq 48, length 64
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Насколько я понимаю, сервер нормально перенаправляет запросы клиента во внешнюю сеть, однако не понимает, что ответы на них надо вернуть клиенту. С чем это может быть связанно и как это можно исправить?

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

однако не понимает, что ответы на них надо вернуть клиенту.

Пока это не факт. Посмотрите tcpdump на tun интерфейсах на сервере и на клиенте. Вполне возможно, что пакеты дропает клиент, что там в iptables?

mky ★★★★★
()
Ответ на: комментарий от mky

Вот, что видно с сервера, когда клиент пытается пинговать гугл:

# tcpdump -i tun0 "ip proto \icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
00:17:34.856972 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 1, length 64
00:17:35.864048 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 2, length 64
00:17:36.857195 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 3, length 64
00:17:37.863830 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 4, length 64
00:17:38.857171 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 5, length 64
00:17:39.856951 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 6, length 64
00:17:40.864913 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 7, length 64
00:17:41.863982 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 8, length 64
00:17:42.856947 IP 10.8.0.2 > google-public-dns-a.google.com: ICMP echo request, id 15091, seq 9, length 64
^C
9 packets captured
10 packets received by filter
0 packets dropped by kernel

А вот, что видно на клиенте:

$ sudo tcpdump -i tun0 "ip proto \icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:23:16.263867 IP my-notebook > google-public-dns-a.google.com: ICMP echo request, id 15281, seq 1, length 64
03:23:17.271387 IP my-notebook > google-public-dns-a.google.com: ICMP echo request, id 15281, seq 2, length 64
03:23:18.271280 IP my-notebook > google-public-dns-a.google.com: ICMP echo request, id 15281, seq 3, length 64
^C
3 packets captured
4 packets received by filter
0 packets dropped by kernel

Как можно заметить, сервер не пытается отправить ответы клиенту. Кстати, не работает доступ в интернет не только с компьютера, но и с Android-смартфона (с теми же симптомами - сам сервер доступен, интернет за ним - нет), поэтому мне кажется, что вероятность проблемы в настройках клиента мала.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

Это как-то странно. Может на сервере нет маршрута к 10.8.0.0/24 через tun0? Или, может в iptables добавлены ещё какие-то правила. В выводе iptables-save цепочка FORWARD точно пустая?

Попробуйте добавить правило:

iptables -I FORWARD -d 10.8.0.2 -p icmp -j LOG

и посмотреть, срабатывает ли это правило при пинге (растёт счётчик) и что пишется про пакет (входящий/исходящий интерфейсы) в лог-файл.

mky ★★★★★
()
Ответ на: комментарий от mky

Это правило никаких записей в логе не дало. Сделал более общее правило iptables -l FORWARD -p icmp -j LOG, получил:

[148723.011273] IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=26904 DF PROTO=ICMP TYPE=8 CODE=0 ID=30728 SEQ=1 
[148724.015297] IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=26906 DF PROTO=ICMP TYPE=8 CODE=0 ID=30728 SEQ=2 
[148725.008594] IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=27046 DF PROTO=ICMP TYPE=8 CODE=0 ID=30728 SEQ=3

Сделал логгирование всех ICMP-пакетов в цепочках INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING и одиночный пинг теперь выглядит так:

[148998.173360] IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21242 DF PROTO=ICMP TYPE=8 CODE=0 ID=30863 SEQ=1 
[148998.186198] IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=21242 DF PROTO=ICMP TYPE=8 CODE=0 ID=30863 SEQ=1 
[148998.199297] IN= OUT=eth0 SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=21242 DF PROTO=ICMP TYPE=8 CODE=0 ID=30863 SEQ=1 
[149020.033685] IN= OUT=eth0 SRC=192.168.0.2 DST=8.8.8.8 LEN=196 TOS=0x00 PREC=0xC0 TTL=64 ID=3119 PROTO=ICMP TYPE=3 CODE=3 [SRC=8.8.8.8 DST=192.168.0.2 LEN=168 TOS=0x00 PREC=0x00 TTL=246 ID=50331 PROTO=UDP SPT=53 DPT=46424 LEN=148 ]

192.168.0.2 - адрес сервера в локальной сети (он подключен к интернету через роутер).

Получается, что при получении ответа на пинг сервер забирает его себе, а не перенаправляет дальше в tun0. При использовании NAT вроде же есть какая-то таблица, кому из клиентов за NAT надо послать входящий пакет, получается, что она работает как-то неправильно.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от mky

Кстати, настройку iptables выполняет вот такой скрипт:

#!/bin/bash

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F
iptables -t raw -X
iptables -t security -F
iptables -t security -X
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT # Loopback
iptables -A INPUT -i tun0 -j ACCEPT # OpenVPN
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT # SSH
iptables -A INPUT -p tcp --dport 80 -j ACCEPT # HTTP
iptables -A INPUT -p tcp --dport 443 -j ACCEPT # HTTPS
iptables -A INPUT -p udp --dport 1194 -j ACCEPT # VPN
iptables -A INPUT -p tcp --dport 5222 -j ACCEPT # Jabber Client
iptables -A INPUT -p tcp --dport 5280 -j ACCEPT # Jabber BOSH
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE # VPN NAT
KivApple ★★★★★
() автор топика
Ответ на: комментарий от KivApple

Логирование во всех цепочках это хорошо, но желательно использовать ″--log-prefix″, чтобы было понятно, в какой цепочке сработало ″-j LOG″ правило. Или использовать -j TRACE . Хотя в данном случае это не так важно.

...ответа на пинг сервер забирает его себе

Не похоже, я вобще не вижу в логе ответа на пинг. Там нет пакета с ″IN=eth0″ или с ″TYPE=0″ (Echo Reply). Пакет с SRC=192.168.0.2 не связан с предыдущими. Но тоже странный, в нём сервер сообщает google-dns'у, что порт недоступен, это похоже на то, что сервер сделал dns-запрос, получил ответ, сокет и запись в conntrack удалились и тут пришёл ещё один пакет с DNS-ответом.

Больше похоже, что пакет с ответом на ping вобще не попадает в iptables, а уничтожается раньше. Почему такое может быть в вашем случае я пока не знаю. Покажите ещё раз tcpdump icmp пакетов на eth0, но с опциями ″-e -n -nn -vvv″, может что прояснится.

mky ★★★★★
()
Ответ на: комментарий от mky 
# tcpdump -e -n -nn -vvv -i eth0 "ip proto \icmp"
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:11:51.612403 02:8e:06:c3:2f:12 > 10:fe:ed:8f:6e:12, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 54639, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.2 > 8.8.8.8: ICMP echo request, id 31767, seq 1, length 64
23:11:51.649283 10:fe:ed:8f:6e:12 > 02:8e:06:c3:2f:12, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 246, id 35406, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.0.2: ICMP echo reply, id 31767, seq 1, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Кстати, в одну из моих попыток захвата трафика с помощью tcpdump попался какой-то пакет со сообщениями про DNS и Dropbox. А у меня на ноутбуке как раз он запущен. Думаю, при смене сети Dropbox попытался приконнектится и это и создало «левый» пакет на предыдущем логе.

KivApple ★★★★★
() автор топика
Ответ на: комментарий от KivApple

″02:8e:06:c3:2f:12″ точно mac-адрес сетёвки вашего сервера, просто производитель по ″02:8e:06″ не гуглится.

Попробуйте во время пинга посмотреть что там в таблице соединений на сервере: 

conntrack -L -p icmp
″conntrack″ это команда, не знаю как называется пакет, возможно в conntrack-tools.

Ещё попробуйте засунуть ″-j LOG″ в PREROUTING (в таблицы raw, nat, mangle), может где ответ от 8.8.8.8 проявится.

mky ★★★★★
()
Ответ на: комментарий от mky

Да, это действительно MAC-адрес сервера. Это если что одноплатник CubieBoard2, не знаю, что за сетевой чип туда засунули.

# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::8e:6ff:fec3:2f12  prefixlen 64  scopeid 0x20<link>
        ether 02:8e:06:c3:2f:12  txqueuelen 1000  (Ethernet)
        RX packets 104396  bytes 19180192 (18.2 MiB)
        RX errors 0  dropped 17  overruns 0  frame 0
        TX packets 8148  bytes 1416008 (1.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 43

Результат логгирования пакетов через -j LOG:

[243986.816783] raw IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=61164 DF PROTO=ICMP TYPE=8 CODE=0 ID=28615 SEQ=1 
[243986.829847] mangle IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=61164 DF PROTO=ICMP TYPE=8 CODE=0 ID=28615 SEQ=1 
[243986.843113] nat IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=61164 DF PROTO=ICMP TYPE=8 CODE=0 ID=28615 SEQ=1 
[243986.890598] raw IN=eth0 OUT= MAC=02:8e:06:c3:2f:12:10:fe:ed:8f:6e:12:08:00 SRC=8.8.8.8 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=247 ID=47838 PROTO=ICMP TYPE=0 CODE=0 ID=28615 SEQ=1 
[243986.907285] mangle IN=eth0 OUT= MAC=02:8e:06:c3:2f:12:10:fe:ed:8f:6e:12:08:00 SRC=8.8.8.8 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=247 ID=47838 PROTO=ICMP TYPE=0 CODE=0 ID=28615 SEQ=1

Результат выполнения команды conntrack:

# conntrack -L -p icmp
icmp     1 18 src=10.8.0.2 dst=8.8.8.8 type=8 code=0 id=28615 src=8.8.8.8 dst=192.168.0.2 type=0 code=0 id=28615 mark=0 use=1
conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown.

Ответный пакет попадает в iptables, насколько я понимаю, проходит таблицы raw и mangle, но в таблицу nat почему-то не идёт.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

В принципе не важно какой чип, я просто думал, вдруг какое чудо и mac-адрес «левый», поэтому его ядро не принимает, но раз пакет есть в raw и mangle, значит пакет ядром принимается. В nat он попадать не должен, туда попадают только первый пакеты соединения (state=NEW). Переписывание адреса у ответного пакета (обратный SNAT) идёт без участия таблицы nat, исключительно по записе в conntrack. Запись в conntrack нормальная, более того, в ней нет слова ″[UNREPLIED]″, значит conntrack получил ответный icmp-пакет от гугла.

После conntrack принимается решение о маршрутизации (routing decision) и дальше таблица mangle цепочка, либо INPUT, либо FORWARD. Если там пакета нет, то мне не понятно почему.

Ну, так есть rp_filter, но он ЕМНИП, до conntrack и, раз на самом компе инет работает, то не ваш случай. Существует blackhole-маршрут, но не думаю, что вы смогли такое прописать. Ну ещё, может быть, пакет признаётся марсианским и уничтожается, сомневаюсь в этом, но попробуйте включить их логгирование (если выключено): 

echo 1 > /proc/sys/net/ipv4/conf/eth0/log_martians

mky ★★★★★
()
Ответ на: комментарий от mky 
[37568.848974] mangle-prerouting IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35755 DF PROTO=ICMP TYPE=8 CODE=0 ID=6613 SEQ=1 
[37568.863147] mangle-forward IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=35755 DF PROTO=ICMP TYPE=8 CODE=0 ID=6613 SEQ=1 
[37568.914012] mangle-prerouting IN=eth0 OUT= MAC=02:8e:06:c3:2f:12:10:fe:ed:8f:6e:12:08:00 SRC=8.8.8.8 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=246 ID=37975 PROTO=ICMP TYPE=0 CODE=0 ID=6613 SEQ=1

Пакет не попадает ни в mangle forward, ни в mangle input, только в mangle prerouting.

Попробовал iptables -t raw -A PREROUTING -p icmp -j TRACE:

[37756.525419] TRACE: raw:PREROUTING:policy:2 IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.540730] TRACE: mangle:PREROUTING:policy:1 IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.556259] TRACE: nat:PREROUTING:policy:1 IN=tun0 OUT= MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.571577] TRACE: mangle:FORWARD:policy:1 IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.587174] TRACE: filter:FORWARD:policy:1 IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.602781] TRACE: security:FORWARD:policy:1 IN=tun0 OUT=eth0 MAC= SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.618544] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=eth0 SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.633710] TRACE: nat:POSTROUTING:rule:1 IN= OUT=eth0 SRC=10.8.0.2 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=55897 DF PROTO=ICMP TYPE=8 CODE=0 ID=6774 SEQ=1 
[37756.685133] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:8e:06:c3:2f:12:10:fe:ed:8f:6e:12:08:00 SRC=8.8.8.8 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=246 ID=23248 PROTO=ICMP TYPE=0 CODE=0 ID=6774 SEQ=1 
[37756.704041] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=02:8e:06:c3:2f:12:10:fe:ed:8f:6e:12:08:00 SRC=8.8.8.8 DST=192.168.0.2 LEN=84 TOS=0x00 PREC=0x00 TTL=246 ID=23248 PROTO=ICMP TYPE=0 CODE=0 ID=6774 SEQ=1

Видно, что пакет теряется после mangle prerouting. Логгирование марсианских пакетов включил, но в dmesg дополнительных строчек нету.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Правило для iptables на prerouting
Admin
zfs cpu →