Puncte:0

de ce MASQUERADE SNAT poate bloca conexiunea localhost?

drapel jp

Am observat un comportament ciudat pe Linux:

În primul rând, curăț toate rutele și regulile iptables:

IP route flush table main
tabelul de golire a rutei ip implicit
IP route flush table local
iptables -P INTRARE ACCEPT
iptables -P FORWARD ACCEPT
iptables -P ACCEPT IEȘIRE
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
ip6tables -P ACCEPT INTRARE
ip6tables -P FORWARD ACCEPT
ip6tables -P ACCEPT IEȘIRE
ip6tables -t nat -F
ip6tables -t mangle -F
ip6tables -F
ip6tables -X

Apoi adaug o rută locală:

IP route add local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 table local

Apoi, pe un terminal deschid un port cu nc -lp 12345 iar pe alt terminal cu care ma conectez la el nc 127.0.0.1 12345 și pot trimite și primi date între serverul netcat și client. Deci, deocamdată, totul este bine.

Acum, de pe el și după ce am ucis serverul și clientul netcat anterior, dacă rulez:

iptables -t nat -A POSTROUTING -j MASQUERADE

și repornesc serverul netcat, apoi clientul nu se conectează. Stii de ce?

Observ că adăugarea IP route add local 192.168.0.10 dev wlan0 proto kernel scope host src 192.168.0.10 table local faceți ca conexiunea netcat să funcționeze din nou. Totuși, nu înțeleg de ce interfața wlan0 (care are 192.168.0.10 ca IP) poate influența interfața loopback?

Pentru informații, folosesc ArchLinux

Saïmonn avatar
drapel in
Bănuiesc că regula MASQUERADE schimbă portul pachetului sursă, încurcând astfel pachetul de returnare. Ați putea publica o ieșire de la un tcpdump care rulează pe localhost în timp ce vă jucați cu netcat? Sunt sigur că acest lucru ne-ar putea aduce mai aproape de un răspuns verificabil.
Puncte:1
drapel in

Nu știu dacă este o eroare sau un comportament de rezervă intenționat, dar din ce se poate vedea aici, nu are nicio legătură cu wlan0 ruta locală pe care ați menționat-o sau toate gateway-ul implicit bla bla (fără supărare, dar aproape că nu are sens pentru mine) menționate în celălalt răspuns/„corect”.

În mod normal cum MASCARADĂ funcționează este că alege adresa care este configurată pe outbound interfață (care este determinată de rutare, prin urmare POSTOUTARE) pentru sursa NAT pe care o realizează. (Dacă sunt atribuite mai multe adrese pe interfață, probabil că va alege prima sau cea care este setată ca adresă sursă preferată în ruta corespunzătoare; nu sunt atât de familiarizat cu aceasta și asta nu este în afara domeniului de aplicare aici oricum). Nu are nimic de-a face cu adresa nexthop / gateway a rutei implicite. (NAT sursă nu funcționează oricum așa.)

Cu toate acestea, când vine vorba de interfață uite, lucrurile par să devină puțin complicate. Mai exact, nu pare să aibă vreo legătură cu interfața în sine (în afară de faptul că va fi interfața de ieșire deoarece destinația este o adresă locală), ci mai degrabă faptul că, adresele din 127.0.0.0/8 blocul nu intră în domeniul de aplicare global. Deși habar n-am ce se întâmplă în spatele scenei, se pare că traficul nu poate „apari” dacă gazda nu are niciun scop. global Adresă IP configurată, dar încercați MASCARADĂ.

Ceea ce pot vedea aici este, chiar dacă doar configurați o adresă care este valabilă pentru domeniu global (de exemplu. 192.168.0.10/32) pe orice interfață (inclusiv uite), veți vedea că funcționează din nou. (Ruta locală pe care ați menționat-o va fi adăugată automat.Dar nu văd că adăugarea doar a traseului funcționează aici.)

Pentru cât merită, adresele și interfețele nu sunt puternic legate între ele în Linux (nu într-un mod simplu, cum ar fi, va răspunde la traficuri numai dacă adresa lor de destinație se potrivește cu adresa configurată pe interfața de intrare, chiar și atunci când redirecționarea IP este nu de îngrijorare). Deci s-ar putea să aibă ceva de-a face cu asta: în caz MASCARADĂ nu pot alege un domeniu global adresa din ceea ce sunt configurate pe interfața de ieșire, alege doar una dintre oricare (mă îndoiesc că prioritatea are ceva de-a face cu ruta implicită), dacă tot nu, pur și simplu refuză să funcționeze într-un fel.

În cazul în care aveți nevoie într-adevăr de o regulă care să permită MASCARADĂ pe toate interfețele dar uite, poti avea:

iptables -t nat -A POSTROUTING ! -o lo -j MASCARATĂ
Puncte:1
drapel us

Aceasta este o presupunere educată. The MASCARADĂ opțiunea înlocuiește adresa IP sursă din pachetele IP cu adresa pe care decide să o folosească. Cred că în acest caz, înlocuiește adresa sursă cu adresa interfeței unde este accesibil gateway-ul implicit.

Deci, dacă gateway-ul dvs. implicit este 192.168.0.1, adresa sursă a pachetului este înlocuită cu 192.168.0.1. Destinația este 127.0.0.1, iar acest lucru nu funcționează corect.

Ar trebui să limitezi MASCARADĂ la numai pachetele în care interfața de ieșire este cea către gateway-ul implicit.

O poți face cu următoarea comandă:

iptables -t nat -A POSTROUTING -o <dacă> -j MASQUERADE
Puncte:0
drapel jp

Pe lângă celelalte răspunsuri, am făcut și alte experimente. Vă rugăm să rețineți că următoarele sunt doar concluziile mele, nu am căutat în sursa kernelului (dar dacă aveți documentație, vă rugăm să distribuiți).

Într-adevăr, se pare că uite interfață și 127.0.0.1 urmează propriile reguli.

Pentru celelalte interfețe, iată cum cred că IP-ul sursă este atribuit unui pachet (fără a vorbi despre MASQUERADE sau lucruri precum socket-uri brute):

Când cineva încearcă să trimită un pachet către o IP de estimare, Linux va căuta o regulă de rutare care se potrivește adăugată ca:

ip route add <NETWORK>/<PREFIX> dev <INTERFACE_XX> [src <SRC_IP>]

Dacă parametrul src este furnizat (acest lucru pare să implice adăugarea unei reguli precum ip route add local <SRC_IP> dev <INTERFACE_YY> inainte de. Rețineți că INTERFACE_XX și INTERFACE_YY nu trebuie să fie la fel, în mod destul de surprinzător), apoi pachetul este trimis pe interfață INTERFACE_XX cu SRC_IP ca IP sursă.

Dacă parametrul src nu este furnizat, va trimite pachetul INTERFACE_XX iar adresa sursă este selectată prin căutarea primului IP valid pe o interfață de la primul început până la ultimul (cu excepția lui lo). Dacă nu este găsit niciun IP, IP-ul sursă este setat la 0.0.0.0. Dacă o interfață are IP-uri multiple, îl alege pe primul. În mod destul de surprinzător, acest lucru înseamnă că un pachet nu are neapărat IP-ul interfeței de ieșire către care este trimis.

Bănuiesc că MASQUERADE alege IP-ul sursă într-un mod similar.

Te rog corectează-mă dacă crezi că ceva este greșit.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.