Cum să împiedicați netfilter să schimbe automat porturile sursă

Am observat că netfilter schimbă portul sursă atunci când se stabilește o conexiune în modulul conntrack. Trebuie să previn acest comportament.

Iată ce am făcut pentru a reproduce problema mea:

1. Creez o regulă netfilter care va efectua DNAT din portul 2002 până în 2003

sudo iptables -w -t nat -A OUTPUT -s 192.168.30.3 -d 192.168.30.1 -p udp --sport 2001 --dport 2002 -j DNAT --to-destination :2003

2. Apoi creez o intrare conntrack pentru a simula o conexiune de la 192.168.30.1:2001 (Computerul meu) la 192.168.30.1:2003

sudo /sbin/conntrack -I -s 192.168.30.1 -d 192.168.30.3 -p udp --sport 2003 --dport 2001 --timeout 100000

3. În cele din urmă, efectuez o conexiune la 192.168.30.1:2002 de pe computerul meu cu portul sursă 2001:

sudo nc -u -p 2001 192.168.30.1 2002

Datorită regulii DNAT netfilter, mă așteptam la un pachet de ieșire cu portul de destinație 2003 și portul sursă 2001. Cu toate acestea, pe wireshark am observat că portul sursă s-a schimbat la un număr aleatoriu. Bănuiesc că acest lucru se datorează faptului că computerul meu consideră că există o conexiune existentă pe portul 2001 (datorită intrării conntrack) și apoi împiedică portul sursă să fie 2001 (nu?). Dar nu vreau acest comportament? Cum pot forța utilizarea numărului de port 2001?

Pentru ca DNAT-ul să funcționeze (în sensul că, pentru ca programul pornit să poată recunoaște răspunsurile), „reverse NAT” care schimbă portul sursă al traficurilor de răspuns din 192.168.30.1 (la 192.168.30.3:2001) din 2003 la 2002 va trebui efectuată.

Totuşi, când sunt traficuri care vin din 192.168.30.1:2003 la 192.168.30.3:2001 că din punctul de vedere al conntrack nu sunt o consecință a DNAT-ului (deoarece conform intrării conntrack creată, gazda nu este cea care a inițiat conexiunea), NAT-ul invers va fi inadecvat.

Prin urmare, netfilter este „forțat” să efectueze și SNAT pentru traficurile care se potrivesc cu regula DNAT, astfel încât să poată diferenția traficurile de răspuns (adică și de 192.168.30.1:2003) după destinație 192.168.30.3:$aleatoriu.

Presupun ca netfilter fie va efectua NAT invers pentru DNAT (care este un SNAT) înainte de NAT invers pentru SNAT (care este un DNAT), fie va reuși să folosească destinația înainte de NAT invers pentru SNAT (adică. 192.168.30.3:$aleatoriu) ca potrivire pentru NAT invers pentru DNAT, altfel SNAT forțat va fi inutil.(În cazul nereversării, totuși, niciuna dintre acestea nu este adevărată AFAIK: DNAT va fi efectuat în PREROUTING înainte de SNAT în INPUT, iar potrivirea destinației în regula SNAT, dacă există, va folosi valoarea rezultată în DNAT)

Chestia este că povestea de mai sus / „problema” din întrebarea ta nu are nici un sens în realitate. Luați ca exemplu un VPN wireguard cu două gazde: să presupunem că doriți să aveți Punct final= setat pe ambele gazde (astfel încât oricare dintre ele să poată iniția comunicarea) și nu doriți ca valorile să fie „actualizate” în mod neașteptat din cauza SNAT-ului forțat (presupunând că ar putea fi declanșat), ceea ce ar trebui să faceți este pur și simplu un „întotdeauna -on" SNAT care "completează" DNAT / este echivalent cu NAT de rezervă:

iptables -t nat -A INPUT -s 192.168.30.1 -d 192.168.30.3 -p udp --sport 2003 --dport 2001 -j SNAT --to-source :2002

care în mod normal nu este necesar în modelul client-server din cauza NAT-ului invers automat pentru DNAT.

P.S. Încă nu ar trebui să ajungi 192.168.30.1:2003 de 192.168.30.1:2003 totuși, în caz contrar, NAT-ul sursă forțată va apărea și dacă îl ajungeți din nou până la 192.168.30.1:2002 înainte ca intrarea conntrack a fostului să fie abandonată. Nici regula SNAT suplimentară din INPUT nu ar trebui să vă provoace probleme suplimentare.

Puteți seta două fluxuri care în mod normal s-ar ciocni în contratrack tabelul de căutare (declanșând astfel, de obicei, o rescriere a portului sursă pe noul flux pentru a evita coliziunea) să fie în diferite zone de contratrack. Această proprietate suplimentară de zonă face contratrack nu se potrivește/se ciocnește cu un flux existent într-o zonă conntrack diferită: nu va avea loc nicio rescriere a portului sursă.

Pentru exemplul dvs. specific, iată o regulă specifică care va preveni coliziunea și, astfel, va preveni rescrierea portului sursă:

iptables -t raw -A OUTPUT -s 192.168.30.3 -d 192.168.30.1 -p udp --sport 2001 --dport 2002 -j CT --zone-orig 1

În mod normal, în funcție de cazul de utilizare, se folosește un selector mai sensibil. Este adesea folosit în lanțul PREROUTING cu o interfață de intrare ca selector la rutare și adesea asociat cu o valoare de marcare, astfel încât rutarea poate fi și ea afectată.

Cazul de utilizare original care a făcut să apară această opțiune este când contratrack pe aceeași stivă de rețea (fără spațiu de nume de rețea suplimentar) cu o configurație complexă de rutare (de exemplu: rutare între 4 rețele LAN private diferite folosind aceleași adrese IP. de exemplu, între 192.168.1.0/24 eth0 <-> eth1 10.1.0.0/24 și din nou 192.168.1.0/24 eth2 <-> 10.1.0.0/24 eth3) poate vedea două fluxuri neînrudite cu aceleași adrese/porturi. La fel de Netfilter și contratrack nu știu nimic despre rutare ( contratrack tabelul de căutare include numai adrese) ei trebuie învățați să ia în considerare aceste fluxuri separat, adăugând o proprietate de zonă legată manual de topologia de rutare în contratrack tabel de căutare.

(Iată un Link LWN când caracteristica a fost propusă inițial.)

NAT modifică portul sursă pentru a reduce riscul unui conflict de port, ce ar trebui să se întâmple dacă acel sport 2002 este deja ocupat pe mașina NAT?

Dacă aveți cerințe specifice pentru anumite porturi, puteți adăuga anumite porturi SNAT reguli pentru asta, dar din nou, ce se întâmplă dacă mai mulți clienți interni încearcă să folosească același port sursă?

Aici ar trebui să ne întoarcem și să recunoaștem că NAT este un hack care a fost creat pentru a reduce problema lipsei adreselor IP publice. Adevărata soluție aici este ca toată lumea să aibă IP-uri publice non-NAT.

Când vorbim despre NAT în zilele noastre, cel mai adesea ne referim la adrese IP private din spatele unui IP. În aceste cazuri, de fapt, este NAPT A Întrebare similară legată de asta, mă gândeam MASCARADĂ țintă și nu DNAT