Tisknout stránku - Ping přes konkrétní rozhraní vs. nastavení směrování

Mám dvě rozhraní umožňující připojení k Internetu wlp3s0 (WiFi) a enp0s26u1u2 (USB tethering). Směrování a IP jsou nastaveny takto:

Kód: [Vybrat]

$ ip r
default via 10.0.0.138 dev wlp3s0 proto dhcp src 10.0.0.8 metric 303 
default via 10.42.0.1 dev enp0s26u1u2 proto dhcp metric 1000 
10.0.0.0/24 dev wlp3s0 proto dhcp scope link src 10.0.0.8 metric 303 
10.42.0.0/24 dev enp0s26u1u2 proto kernel scope link src 10.42.0.78 metric 1000

$ ip a
..
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 60:67:20:d8:bc:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 85786sec preferred_lft 74986sec
..
211: enp0s26u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether f6:80:23:7e:37:6f brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.78/24 brd 10.42.0.255 scope global dynamic noprefixroute enp0s26u1u2
       valid_lft 2797sec preferred_lft 2797sec
    inet6 fe80::a1a9:83a0:b0ae:dd2e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Čekal bych, že

Kód: [Vybrat]

$ ping -I enp0s26u1u2 8.8.8.8 nebo

Kód: [Vybrat]

$ curl --interface enp0s26u1u2 osel.cz projdou bez ohledu na prioritu (matric), když routa existuje, ale neděje se tak. Je to korektní chování? A pokud ano, nějaký trik na otestování průchodnosti, aniž bych musel do stavu sítě jakkoliv zasahovat?

korektni to neni na routeru to mam podobne (wan-eth z wifi, wwan-usb lte, wwan mi take hlasi stav unknown, v route ma moboje jak ty) a ping pres -I wwan0 normalne projde (a jde jiste pres wwan)

(upřesňuji - jde o noťas. Pro pobavení - honil jsem díky tomu duchy na PinePhone úplně zbytečně ::) a hlavně dlouho ;D)

Předpokládám, že ty odchozí pakety normálně projdou – pokud tam nemáte nastavená ještě nějaká pravidla. Podívejte se přes tcpdump, co skutečně z rozhraní odchází. Nemáte tam ještě nějaký NAT? Pokud se nastaví odchozí IP adresa sítě A a paket pak odejde sítí B, vrátí se odpověď sítí A (podle původní zdrojové IP adresy) – a pokud se v síti A dělá NAT, odpověď neprojde, protože pro ni chybí v NATu záznam v tabulce spojení.

@FJ: Skvělý odhad 8) NixOS má firewall jako výchozí nastavení (https://search.nixos.org/options?channel=21.05&show=networking.firewall.enable&from=0&size=50&sort=relevance&type=packages&query=networking.firewall) (dobré vědět :) ). Po vypnutí pomoci systemctl stop firewall ping (interval 3 s) prošel, na rozhraní ze strany noťasu se návratové pakety objevovaly celou dobu

Kód: [Vybrat]

tcpdump -i enp0s26u1u2 -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s26u1u2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:01:31.570551 IP 10.42.0.78 > 8.8.8.8: ICMP echo request, id 128, seq 146, length 64
22:01:31.634330 IP 8.8.8.8 > 10.42.0.78: ICMP echo reply, id 128, seq 146, length 64
22:01:34.578521 IP 10.42.0.78 > 8.8.8.8: ICMP echo request, id 128, seq 147, length 64
22:01:34.627137 IP 8.8.8.8 > 10.42.0.78: ICMP echo reply, id 128, seq 147, length 64

Tedy mise splněna = vím, čím testovat, co mě oprávněně mátlo a jak se toho zbavit. Díky!

Ale rád bych věc pochopil až do konce. Nerozumím tomu, jak dojde ke "schování" návratových paketů před ping/curl/..). Nastavení je:

Kód: [Vybrat]

iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      11M   14G LIBVIRT_INP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2     2386  640K nixos-fw   all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LIBVIRT_FWX  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2        0     0 LIBVIRT_FWI  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
3        0     0 LIBVIRT_FWO  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 2582 packets, 405K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    6303K  498M LIBVIRT_OUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_FWI (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
2        0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWO (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0           
2        0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWX (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_INP (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
2        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
3        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
4        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

Chain LIBVIRT_OUT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:53
2        0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
3        0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
4        0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:68

Chain nixos-fw (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1      414  221K nixos-fw-accept  all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2     1947  416K nixos-fw-accept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
3        0     0 nixos-fw-accept  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
4        0     0 nixos-fw-accept  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
5       25  3112 nixos-fw-log-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-accept (4 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     2361  637K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-log-refuse (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 LOG flags 0 level 6 prefix "refused connection: "
2       24  3072 nixos-fw-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PKTTYPE != unicast
3        1    40 nixos-fw-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-refuse (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       25  3112 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Citace: Ladislav Nešněra 25. 10. 2021, 22:19:34

Ale rád bych věc pochopil až do konce. Nerozumím tomu, jak dojde ke "schování" návratových paketů před ping/curl/..). Nastavení je:
Kód: [Vybrat]
iptables -nvL --line-numbers Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 11M 14G LIBVIRT_INP all -- * * 0.0.0.0/0 0.0.0.0/0 2 2386 640K nixos-fw all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LIBVIRT_FWX all -- * * 0.0.0.0/0 0.0.0.0/0 2 0 0 LIBVIRT_FWI all -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 LIBVIRT_FWO all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 2582 packets, 405K bytes) num pkts bytes target prot opt in out source destination 1 6303K 498M LIBVIRT_OUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain LIBVIRT_FWI (1 references) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED 2 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain LIBVIRT_FWO (1 references) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 2 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain LIBVIRT_FWX (1 references) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 Chain LIBVIRT_INP (1 references) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 2 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 3 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 4 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Chain LIBVIRT_OUT (1 references) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:53 2 0 0 ACCEPT tcp -- * virbr0 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 3 0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68 4 0 0 ACCEPT tcp -- * virbr0 0.0.0.0/0 0.0.0.0/0 tcp dpt:68 Chain nixos-fw (1 references) num pkts bytes target prot opt in out source destination 1 414 221K nixos-fw-accept all -- lo * 0.0.0.0/0 0.0.0.0/0 2 1947 416K nixos-fw-accept all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 3 0 0 nixos-fw-accept tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 4 0 0 nixos-fw-accept icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 5 25 3112 nixos-fw-log-refuse all -- * * 0.0.0.0/0 0.0.0.0/0 Chain nixos-fw-accept (4 references) num pkts bytes target prot opt in out source destination 1 2361 637K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain nixos-fw-log-refuse (1 references) num pkts bytes target prot opt in out source destination 1 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 LOG flags 0 level 6 prefix "refused connection: " 2 24 3072 nixos-fw-refuse all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE != unicast 3 1 40 nixos-fw-refuse all -- * * 0.0.0.0/0 0.0.0.0/0 Chain nixos-fw-refuse (2 references) num pkts bytes target prot opt in out source destination 1 25 3112 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

To je firewall z nějakého routeru za tím notebookem? To je pro připojení toho notebooku přes WiFi, to druhé rozhraní notebooku je připojené do úplně jiné sítě? Já vlastně pořád nemám představu, jak ta vaše síť vypadá.

Jinak ten OUTPUT chain, který má všechna pravidla na ACCEPT a pak má i policy ACCEPT je trochu zbytečný, jenom policy by udělala stejnou službu – pokud teda nepotřebujete počítat pakety.

Každopádně by se hodilo vidět ještě výpis NAT pravidel – přidejte k tomu ještě -t nat.

Na procházení iptables pravidel jsem většinou moc línej. Raději vynuluju počítadla paketů, ideální je, když je to nějaké testovací prostředí a můžu zastavit veškerý ostatní provoz, a pak pustím to, co mne zajímá. Ono se pak na počítadlech hezky ukáže, kudy ten paket přesně šel.

Taky může problémy dělat rp_filter (https://wiki.mikrotik.com/wiki/Manual:IP/Settings) (nenašel jsem lepší odkaz, v linuxu jsou hodnoty číselně)
check :sudo sysctl -a | grep -P '\brp_filter'
pokud je >0, tak po "zapnutí" logování
# echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians by měly být vidět v dmesg

Pro "monitoring" se ještě Dá se ještě použít

Kód: [Vybrat]

sudo watch -n 1 -d iptables -nxL FORWARD # x=bez zkratek kMG

Situace je taková, že mám noťas s NixOS (https://en.wikipedia.org/wiki/NixOS), zaujalo mě hlavně deklarativní nastavení, leč explicitně zmíněný firewall (https://gitlab.com/nesnera/nix_configs/-/blob/daadaddb0c61724e5ccddbd53e7e8cf3fd828af9/ln_configuration.nix#L153) jsem přehlédl. Vlastně jsem na firewall resp. nastavování sítě na Linuxu více narazil až nyní díky laborování s USB tetheringem (https://cs.wikibooks.org/wiki/PinePhone_prakticky#Sdílení_internetového_připojení_(tethering)) na PinePhone (čti kapesní linuxová adventura ;D ) a tedy potřebou kontrolovat, které zařízení připojení obstarává.

Kód: [Vybrat]

# iptables --line-numbers -nvL -t nat
Chain PREROUTING (policy ACCEPT 39798 packets, 3216K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 6 packets, 540 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 147K packets, 12M bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 147K packets, 12M bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     147K   12M LIBVIRT_PRT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_PRT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    40 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24        
2        0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255     
3        0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
4       53  3965 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
5        2   168 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24

Těch rozhraní je na noťasu víc (např. od libvirt nebo interní 3G modul), tak raději celé, ať nematu

Kód: [Vybrat]

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 3c:97:0e:51:30:b7 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 60:67:20:d8:bc:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 78851sec preferred_lft 68051sec
5: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:0b:ed:2b brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
251: wwp0s20u4i6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 76:77:56:98:4c:7b brd ff:ff:ff:ff:ff:ff
253: enp0s26u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether f6:80:23:7e:37:6f brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.78/24 brd 10.42.0.255 scope global dynamic noprefixroute enp0s26u1u2
       valid_lft 3279sec preferred_lft 3279sec
    inet6 fe80::a1a9:83a0:b0ae:dd2e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Skutečně mám net.ipv4.conf.enp0s26u1u2.rp_filter = 2, ale nezdá se, že by se "zapnutí" logování nějak projevilo na výpisu (# dmesg -WH). Zkusil jsem i to watch (díky, úplně jsem zapomněl, že existuje) s iptables, ale vrací jen nuly.

Nevidím v těch pravidlech nic, co by mne na první pohled trklo „tohle je špatně“. Nejsem si úplně jistý, jak bude fungovat ta kombinace volby odchozího rozhraní, dvou výchozích bran a maškarády. Z tcpdumpu výše je vidět, že mají pakety očekávanou zdrojovou IP adresu, ale je nastavená hned při vytvoření paketu, nebo to udělá až maškaráda?

Zkusil bych dvě věci. Jednak pustit ten tcpdump i se zapnutým firewallem – uvidíte, jestli vůbec nějaký paket odejde a máte se zaměřit na to, co se děje s příchozím paketem. Nebo žádný paket neodejde (nebo na něm bude něco špatně), pak víte, že je chybně odchozí směr. Za druhé bych zkusil ponechat zapnutý firewall a vypnout jenom NAT (vyprázdnit ten POSTROUTIG chain) a opět to vyzkoušet (včetně tcpdumpu). Tím zjistíte, jestli je chyba v NATu nebo ve firewallu.

Ona tedy asi spíš bude ve firewallu, když jste „vypnul firewall“ a fungovalo to, byl pravděpodobně vypnutý i NAT, tudíž ty odchozí IP adresy jsou nastavené rovnou správně podle routovací tabulky. Ale je lepší si něco ověřit dvěma různými způsoby, než hledat chybu někde, kde není.

Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: Ladislav Nešněra 24. 10. 2021, 22:57:43