tcppdump vypisuje nezNATovené adresy

tcppdump vypisuje nezNATovené adresy
« kdy: 17. 08. 2021, 12:24:34 »
Zdravím, tohle patří na pomezí  sítě - utility. Přes ssh jsem si na routeru prohlížel tcpdump . wlan1 je WAN s 10.2.0.0/24 a na druhém rozhraní(nejmenované) je místní LAN 192.168/24,  ze které jsem měl připojen smartphone.

Kód: [Vybrat]
sudo tcptump -n -i wlan1 "ip" -t "net 192.168.1.0/24
sudo tcptump -n -i wlan1 "ip" -t "host not 10.2.0.14/24

(Příkaz uvádím, jak byly zadané, takže tam je i nesmyslně "ip")

Oba dělají v podstatě to samé (ale je to jinak formulované, první říká traffic na WAN s IP LAN, ale jelikož mám v iptables MASQUERADE, tak by se tam nemělo vyskytovat 192.168 vůbec, ale 10.2.0.14!. Druhý to říká jen přes negaci: provoz na WAN s jinou adresou než adresu WAN *)

No překvapilo mě že tcpdump vypisoval:

Kód: [Vybrat]
IP 192.168.1.99.56789 > 13.14.15.15:443 Flags <R> win 0 length 0
IP 192.168.1.99.56789 > 114.114.115.115:853 Flags <R> win 0 length 0

Co ale je divné, že se to stávalo pouze při speedtestu při uploadu. Jako kdyby NAT nestíhal. Vícekrát a pravidelněji se tam ukazovala první IP (port 443). A občas se tam ukazovala IP druhá (port 853 - DNSoverTLS) v menším počtu a méně častěji. Dělá to na 2 speedstestech.

Je pro to nějaké vysvětlení proč se to děje? Je to chyba natu a nebo jen chyba výpisu. Máte tip, jak to ověřit , když dál nez na ten router nedosáhnu?

* Není to uplně přesné, to ví každý, kdo v wiresharku napsal ip not 192.168.1.2, ale asi myslel !(ip == 192.168.1.2), proto to taky poddtrhuje žlutě. Ale pro příklad je to jedno.
« Poslední změna: 17. 08. 2021, 15:00:42 od Petr Krčmář »


Re:tcppdump vypisuje nezNATovené adresy (Při velkém uploadu)
« Odpověď #1 kdy: 17. 08. 2021, 14:30:57 »
Mohl by jsi doplnit konfiguraci firewallu?

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #2 kdy: 17. 08. 2021, 18:55:28 »
Zde (rád se nechám poučit, jak to udělat "fortelně", nejsem v tom uplně si jistý, mám tam i pár věci zbytečně víckrát)
Kód: [Vybrat]
pocitac:~ $ sudo iptables -nvL
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   176 DROP       all  --  *      *       10.2.0.0/24       0.0.0.0/0 ## nechci se nechat rušit pakety odvedle
    0     0 REJECT     all  --  *      *       0.0.0.0/0            10.2.0.0/24       reject-with icmp-port-unreachable ## nechci odesílat nic do vedlejší sítě
  39M   54G ACCEPT     all  --  wlan1  eth0    0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED # pravidlo pro příchozí spojení
  19M 4650M ACCEPT     all  --  eth0   wlan1   0.0.0.0/0            0.0.0.0/0 ## pravidlo pro odchozí spojení
    0     0 ACCEPT     all  --  eth0   wlan1   192.168.1.0/24       0.0.0.0/0 ## duplicita
    0     0 ACCEPT     all  --  wlan1  eth0    0.0.0.0/0            192.168.1.0/24       ctstate RELATED,ESTABLISHED ## duplicita

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
4842K 7257M ACCEPT     all  --  wlan1  *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED # aby mi šel internet i přímo z tohoto kompu + primitivní čítač dat
61461 2159K DROP       all  --  wlan1  *       0.0.0.0/0            0.0.0.0/0 ## základní firewall
83218 6880K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0 (čítač odchozích dat)

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

pocitac:~ $ sudo iptables -t nat -nvL # PREROUTING INPUT OUTPUT=NIC
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
46059 5394K MASQUERADE  all  --  *      wlan1   0.0.0.0/0            0.0.0.0/0 ## ne asi, o tom to celé je

Taky jsem se pokoušel trasovat traffic sudo watch  -n 1  -d   iptables -nxvL ale to je vidět, že vše chodí přes ty první 2 ACCEPTY (GIGABAJTY DAT). Občas nějaké pakety probliknout v INPUT ty dva poslední, ale to nevím čemu bych přisoudil, klidně to může být nějaký šum z  všeljaké IGMP , arpy, chromecasty, sdílení 137/138.

Taky je zajímavé že sudo watch  -n 1  -d   iptables -nxvL -t nat "tiká" mnohem pomaleji, jako kdyby započítával jen první paket SYN a další by šly přes -t filter ... JAK TO JE???



Taky jsem se na to chtěl podívat přes conntrack -L ve spojitosti s tcpudump -ni any - porovnat čísla portů. Ale až později

[/code]

Pro jistotu taky tabulka směrování:
Kód: [Vybrat]
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkazů Užt Rozhraní
0.0.0.0         10.2.0.250   0.0.0.0         UG    303    0        0 wlan1
169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth0
10.2.0.0        0.0.0.0         255.255.255.128 U     0      0        0 * # ruční zásah , nešlo mi mazat tu automaticky vytvořenou routu níže, tak jsem ji přebil touto (vzniká při připojení k síti)
10.2.0.0        0.0.0.0         255.255.255.0   U     303    0        0 wlan1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0



Změna: Ono to není při velkém uploadu, jak jsem psal, zkrátka náhodně


Taky by mě zajímala vůbec příčina toho trafficu, jestli je to reakce na nějaký předchozí paket, ale jak říkám, musím se podívat na ten conntrack a tcpdump -i any.

Moje hypotézy:
- Nějaké nadměrné pravidlo ACCEPT někde
- chybějící --dst v pravidlu forward --ctstate related
- conntrack uzavře spojení dřív než smartphone a router ho považuje za neplatný a tedy ho nenatuje
- chybějící pravidlo --ctstate INVALID,ATD -j DROP
« Poslední změna: 17. 08. 2021, 19:02:32 od Vietnamka »

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #3 kdy: 17. 08. 2021, 20:09:07 »
Myslel jsem poradi pravidel v jakem jsou definovana..

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #4 kdy: 17. 08. 2021, 21:09:56 »
ale to je vidět, že vše chodí přes ty první 2 ACCEPTY (GIGABAJTY DAT)
Samozřejmě. Uvědomte si, že v každém TCP spojení je všechno kromě prvního paketu v danéme směru ESTABLISHED, takže to zpracují právě tahle dvě pravidla.

Citace
Taky je zajímavé že sudo watch  -n 1  -d   iptables -nxvL -t nat "tiká" mnohem pomaleji, jako kdyby započítával jen první paket SYN a další by šly přes -t filter
Tabulkou filter prochází všechno, ale překlad adres je stavový, takže pravidla se aplikují jen na první paket, další už se překládají podle vytvořené conntrack položky.

Citace
Pro jistotu taky tabulka směrování:
Kód: [Vybrat]
Směrovací tabulka v jádru pro IP
Adresát         Brána           Maska           Přízn Metrik Odkazů Užt Rozhraní
0.0.0.0         10.2.0.250   0.0.0.0         UG    303    0        0 wlan1
169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth0
10.2.0.0        0.0.0.0         255.255.255.128 U     0      0        0 * # ruční zásah , nešlo mi mazat tu automaticky vytvořenou routu níže, tak jsem ji přebil touto (vzniká při připojení k síti)
10.2.0.0        0.0.0.0         255.255.255.0   U     303    0        0 wlan1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
Tomu řádku s hvězdičkou při nejlepší vůli nerozumím, mohl byste místo toho ukázat výstup "ip route show"? (Rant: chtěl bych se někdy dožít toho, že se přestane všude ukazovat tenhle nepřehledný historický formát.)


Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #5 kdy: 17. 08. 2021, 21:23:17 »
>IDONTCARE
Jsi si jistý tou formulací?

Iptables -L je vypisuje v pořadí v jakym platí (index nula nahoře) a to  hraje roli .  Stejně jsou vkládaná parametrem -A(PPEND), takže pořadí vkládání souhlasí s pořadím pravidel . Ostatně proč bych to znepřehledňoval přes -I filter <číslo>...

(Konec konců je to vidět i v té tabulce, že duplicitní pravidlo  níž má hitcounter nula, protože se aplikovalo víc nahoře)

>Michal K.

Citace
ACCEPTY ESTABLISHED & -t nat SYN
Tak nějak jsem si to myslel, ale nevěděl jsem to jistě, tak jsem to uvedl pro doplnění.   

Kód: [Vybrat]
10.2.0.0/25  192.168.0.0/25
holt jsem zvyklý na route než na ip route . Ale koukám že defaultně nepřekládá názvy, takže není problém ho začít používat

Záhada číslo 2:
Jiný počítač v LAN tuhle věc vůbec nezpůsobuje....
Moje doměnka je že buď smartphone má horší wifi signál a packet loss anebo že používá jiný tcp stack co se horlivě snaží navázat víc  TCP spojení najednou.
Klíčové podle mě je že jde o RST

Paralelně jsem měl watch conntrack -L a tcpdump "192.168.1.0/24" a když mi tam v dumpu přibyl nepřeložený RST, zkopíroval jsem si výpis watch:
Kód: [Vybrat]
conntrack:
IP 192.168.1.70.41472 > 172.217.163.214.443: Flags [R], seq 2567623844, win 0, length 0
(pro zkrácení) conntrack:  tcp      6 <řádek> [ASSURED] mark=0 use=1
CLOSE        src=192.168.1.70 dst=172.217.163.214 sport=41470 dport=443 src=172.217.163.214 dst=WAN_IP sport=443 dport=41470
CLOSE        src=192.168.1.70 dst=172.217.163.214 sport=41472 dport=443 src=172.217.163.214 dst=WAN_IP sport=443 dport=41472
ESTABLISHED  src=192.168.1.70 dst=172.217.163.214 sport=41466 dport=443 src=172.217.163.214 dst=WAN_IP sport=443 dport=41466
TIME_WAIT    src=192.168.1.70 dst=172.217.163.214 sport=41468 dport=443 src=172.217.163.214 dst=WAN_IP sport=443 dport=41468

Nebo:

dump:
IP 192.168.1.70.43645 > 217.31.204.102.443: Flags [R], seq 895279268, win 0, length 0
conntrack:
TIME_WAIT src=192.168.1.70 dst=217.31.204.102 sport=43613 dport=443 src=217.31.204.102 dst=wAN sport=443 dport=43613
CLOSE    src=192.168.1.70 dst=217.31.204.102 sport=43615 dport=443 src=217.31.204.102 dst=WAN sport=443 dport=43615
 

Zvláštní je že na některých stránkách (youtube, github,speedtest) se to děje pravidelně a na jiných ne a ne to zreplikovat
« Poslední změna: 17. 08. 2021, 22:01:40 od Vietnamka »

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #7 kdy: 18. 08. 2021, 09:06:57 »
To co vidíte v tcpdump je v pořádku  ;)

tcpdump požívá knihovnu libpcap. Paket dorazí do kernelu, ten pošle kopii paketu do soketu vytvořeném libpcap a paket pak zpracovává dále, nejdříve skrz "netfilter", kde máte filtrovací pravidla a kde se provádí NAT.

příchozí provoz:
drát -> síťovka -> tcpdump -> netfilter/iptables -> routing

odchozí provoz:
iptables -> tcpdump -> síťovka -> drát

Re: nezNATovené adresy - nezachycení firewallem a příčina vzniku ?
« Odpověď #8 kdy: 24. 08. 2021, 19:08:07 »
Tak jsem tady s výsledky. Díky za snahu, ale ty odpovědi vždycky mířily jinam než co (já jsem považoval nebo teď považuji za jádro dotazu  - což je samotná existence takovéhoto provozu).

Jedna odpověď popisovala iptables tabulky a řetězy (vysvětlením mého pozorování, jaké pakety triggrují jaká pravidla)
Druhá vysvětlení netfiltru - reakce na mé "zpochybňování" správnosti výpisu. Ale mě to prostě bylo divné, připustil jsem možnost, že by třeba tcpdump ukazoval chybu



1. Podařilo se mi to "fixnout" filtrem (na začátek chainu)
Kód: [Vybrat]
sudo iptables -I FORWARD -m conntrack --ctstate INVALID    -j DROP
Sledoval jsem iptables -nvL a současně tcpdump -nti ... a otevíral inkrimované weby a sedí to jak p*del na hrnec.  Tady by mohlo  vlákno končit, ale

2. Proč bez tohoto pravidla takové pakety procházejí?
Očekával jsem, že iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE zařídí překlad a tedy nebude možné aby prošel paket s nepřeloženou adresou  Spolu s - P FORWARD DROP

Dál -- a to se rád nechán překvapit, jak takové pakety filtrovat v FORWARD-filter nebo POSTROUTING-nat :

- ono jaksi nejde filtrovat v FORWARD tabulce (iptables -A forward --??? 192.168.1.0/24 -j DROP ) jelikož  ---??? (tedy --src) je přeci adresa zařízení v vnitřní síti   a já ale chci filtrovat po  později
 po té co proběhne ten překlad-nepřeklad (ano vím FORWARD je před POSTROUTING). A je řešení to cpát do mangle nebo raw

- ani nejde
Kód: [Vybrat]
iptables -t nat -A POSTROUTING - j DROP
něco na způsobnat is intended not for filtering , ačkoli to prý v nějakých verzích firewallu(ů) jde
černé na bílém
pxi@xn:~/start $ sudo iptables -t nat -I POSTROUTING --dst 65.77.88.66 -j DROP
iptables v1.8.2 (nf_tables):
The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.

To mě přivádí k otázce (u paketů odchouzích z vnitřní sítě ven), jaktože nat je definován až v postrouting, ale to filtrování proběhne dřív(FORWARD conntrack invalid) - nějaká divná kauzalita .


A ujištění, je tedy INSERT FORWARD --conntrack --state invalid správné řešení?

3. A ta hlavní otázka:
Proč vůbec ty hlavní pakety vznikají ???



OT: zatímco jsem to psal, mě fórum odhlásilo, ale jelikož jsem to tušil, v druhém okně jsem se přihlásil. Opravdu je nějakých 5-15 ta správná doba ???

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #9 kdy: 24. 08. 2021, 23:29:33 »
Par poznamek:

- Mangle je pred nat, tudy ne.

- Hadam ze by se dal vlozit raw packet primo na odchozi rozhrani. Takovy paket by nesel pres nat a nebyl by trackovany.

Dalo by se to otestovat napriklad v Pythonu pomoci socket(AF_PACKET, SOCK_RAW).

Kazdopadne dost zajimavy problem a cenim, ze si to nevzdal.

Re:tcppdump vypisuje nezNATovené adresy
« Odpověď #10 kdy: 24. 08. 2021, 23:45:28 »
- Tracking funguje tak, ze se firewall nauci preklad a pak uz se provadi "mimo firewall". Preklad se provede jednou na zacatku. Firewall dal pouziva jen trackovaci tabulku a neprovadi ho porad dokola.