Tcpdump afișează un port de redirecționare diferit după adăugarea regulii REDIRECT în iptables

Pentru a fi clar: testul OP se face de la sistemul 192.168.1.100 la el însuși, nu de la un sistem de la distanță și asta este cauza problemei. Portul nu a fost schimbat în acest caz, deoarece nicio regulă NAT nu s-a potrivit, în timp ce s-ar fi potrivit dacă ar fi făcut dintr-un sistem la distanță.

Schema de mai jos arată cum este efectuată ordinea operațiunilor pe un pachet:

Motivul este modul în care funcționează NAT pe Linux: iptables vede un pachet în nat tabel numai pentru primul pachet dintr-un nou flux conntrack (care este astfel în stare NEW).

Această regulă funcționează bine atunci când este de la un sistem de la distanță. În acest caz, primul pachet văzut va fi un pachet de intrare:

la portul 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): la portul 30000
--> decizie de rutare --> ... --> proces local de primire pe portul 30000

Toate pachetele următoare din același flux vor avea conntrack să gestioneze direct schimbarea portului (sau inversarea portului pentru răspunsuri) și vor omite orice regulă iptables din nat tabel (așa cum este scris în schema: nat tabel consultat doar pentru NOU conexiuni). Deci, (sărind partea pachetului de răspuns), următorul pachet de intrare va fi supus în schimb:

la portul 8000 --> AF_PACKET (tcpdump) --> conntrack: la portul 30000
--> decizie de rutare --> ... --> proces local de primire pe portul 30000

Pentru un test pe sistem în sine, primul pachet nu este un pachet de intrare, ci un pachet de ieșire. Acest lucru se întâmplă, în schimb, folosind outgoing uite interfata:

proces local client curl --> decizie de rutare --> conntrack --> nat/OUTPUT (nicio regula aici)
--> verificare redirecționare --> AF_PACKET (tcpdump) --> la portul 8000

Și acum acest pachet este reîntors pe uite interfață, reapare ca un pachet care nu mai este primul pachet dintr-o conexiune, așa că urmează al doilea caz ca mai sus: conntrack singur are grijă de NAT și nu apelează nat/PREROUTING. Cu excepția faptului că nu a fost instruit în pasul de dinainte să facă orice NAT:

la portul 8000 --> AF_PACKET (tcpdump) --> conntrack
--> decizie de rutare --> ... -->Nuproces local de primire pe port8000

deoarece nu se ascultă nimic pe portul 8000, sistemul de operare trimite înapoi un TCP RST.

Pentru ca aceasta să funcționeze în sistemul local, a REDIRECŢIONA regula trebuie pusa si in nat/OUTPUT lanţ:

iptables -t nat -I IEȘIRE -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --la-port 30000

Note Aditionale

• dacă carcasa este destinată utilizării de la distanță, nu testați din sistemul local: regulile parcurse de test nu sunt aceleași. Acest lucru face ca testul să nu reflecte realitatea.

  Utilizați doar un spațiu de nume de rețea pentru a crea un sistem de buzunar la distanță în cazul în care nu este disponibil niciun alt sistem. Exemplu care ar trebui să funcționeze cu un sistem care are doar OP-uri nat/PREROUTING guverna si face curl http://192.168.1.100/ (care nu necesită DNS):

  ip netns adaugă sistem la distanță
  link ip adăugați nume vethremote up tip veth peer netns remotesystem nume eth0
  adresa ip adăugați 192.0.2.1/24 dev vethremote
  ip -n adresa sistemului la distanță adăugați 192.0.2.2/24 dev eth0
  ip -n link-ul la distanta seteaza eth0
  ip -n ruta sistemului la distanță adăugați 192.168.1.100 prin 192.0.2.1
  ip netns exec remotesystem curl http://192.168.1.100:8000/
  

• tcpdump și NAT

  tcpdump se întâmplă la AF_PACKET pași din schema de mai sus: foarte devreme pentru intrare și foarte târziu pentru ieșire. Asta înseamnă că pentru un caz de sistem la distanță, nu va captura niciodată portul 30000, chiar și atunci când funcționează. Pentru cazul sistemului local, odată ce nat/OUTPUT este adăugată regula, va captura portul 30000.

  Doar nu aveți încredere orbește în adresa/portul afișat de tcpdump când faci NAT: depinde de caz și de unde are loc captura.