Puncte:1

De ce toată lumea folosește MASQUERADE/SNAT în loc de NAPT/PAT?

drapel in

Poveste

Am o interfață virtuală VPN wireguard wg0 (poate fi orice altceva) și o interfață fizică eth0. Vreau să direcționez pachetele de la VPN la LAN-ul meu sau de la o interfață la o altă interfață.

Aproape toate blogurile, articolele, sfaturile tutoriale folosind MASCARADĂ sau Sursa NAT numai: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

În plus, Mascarada IP este pur și simplu un SNAT (NAT sursă), nu schimbă portul sursă.

Întrebare

  • Greșesc crezând că ar trebui să folosesc a NAPT/PAT in schimb?
  • Pentru a fi complet, cum pot adăuga o regulă NAPT/PAT cu iptables și/sau nftables?

Gânduri

Pot exista conflicte (portul sursă) între pachetele generate de gazdă și transmise de la wg0 (sau orice alte interfețe virtuale/fizice). IMHO NAPT trebuie folosit pentru a evita aceste conflicte.

RFC 2663, traducerea portului adresei de rețea (NAPT)

Puncte:6
drapel za

Ai cumva o distincție greșită între SNAT/MASQUERADE și NAPT/PAT. Nu este acolo.

În Linux, există două tipuri de reguli NAT dinamice, pe care ambele le numiți „NAPT”:

  • sursă NAT, care intenționează să lase adresa de destinație intactă și doar schimbă sursă abordare. Uneori asta voi schimbați și portul sursă. De exemplu, dacă tabelul de urmărire a conexiunii conține deja înregistrarea cu acest particular (proto, src-adr, src-port, dst-addr, dst-port) tuplu (src-addr și src-port sunt după traducere), pentru a putea face o distincție care este care, noua traducere trebuie să folosească alt port src (pentru că acesta este singurul grad de libertate), deci „NAPT” va avea loc inevitabil. Exemplele de reguli de tip SNAT sunt SNAT și MASCARADĂ. Diferența dintre ele este că cu SNAT trebuie să specificați în regulă în ce adresă să se traducă (și, probabil, în ce gamă de porturi să folosească), în timp ce cu MASQUERADE face alegerea în sine, în funcție de interfața care este destinat să iasă pachetul. Ambele urmează să fie instalate în POSTOUTARE lanț, după ce au avut loc cele mai multe alte procesări, inclusiv rutarea pachetului. Acest tip de regulă este folosit pentru a permite ca multe computere să fie ascunse în spatele adresei IP de ieșire unică, de ex. pentru a accesa Internetul pentru LAN și așa mai departe. Aceasta ar include și orice utilizator VPN, dacă intenționați să accesați Internetul prin VPN.
  • NAT de destinație, care lasă adresa sursă așa cum era și actualizează doar destinaţie adresa și, dacă ați configurat-o, portul de destinație, deci aceasta este și regula „NAPT”. Regulile de acest tip sunt DNAT, REDIRECŢIONA, CLUSTERIP și probabil altele, nu le mai amintesc pe toate; acestea sunt instalate în PRERUUTARE lanț, deoarece decizia de rutare ar trebui de obicei schimbată sub influența regulii. Pachetul care a fost destinat inițial mașinii în sine (are adresa sa ca destinație) și urma să fie parcurs INTRARE și a ajuns la un proces local, este în schimb tradus și, după parcurgere REDIRECŢIONA lanțul este transmis în continuare către un alt sistem. Sau vice versa. Unde să mergem, INPUT sau FORWARD, este decizia de rutare pe care trebuie să o schimbăm cu regula. Acest tip de regulă este folosit pentru a face acces la un sistem intern de pe Internet.

Uneori, apropo, ambii regulile pot fi utilizate pentru pachetul unic (și conexiune). Acesta este cazul special, dar util dacă aveți nevoie de pachete de la un sistem extern (deci DNAT trebuie folosit în PREROUTING) să apară ca provenind de la o adresă internă (pentru care SNAT este folosit în POSTROUTING).

În Linux există și regulile statice de tip NAT, cum ar fi NETMAP care este destul de special și rar folosit. Mă îndoiesc că vorbești despre asta și că ai văzut vreo instrucțiune care menționează acest tip de regulă.

Linux face absolut nicio deosebire între adresele private (RFC1918) și publice. Vă puteți NAT subrețeaua publică dacă doriți (dar aceasta va fi o risipă de adrese). Puteți lăsa IP-uri private fără traducere (dar, de obicei, acest lucru nu va duce la nicio conexiune la internet pentru ele).

VPN-ul nu este altceva decât o interfață de rețea suplimentară în mașină și ar trebui tratată ca atare. În consecință, aveți voie să utilizați adrese publice pentru VPN, dacă le aveți. De exemplu, este posibil să am o subrețea /29 direcționată către un router VPN și să configurez OpenVPN, astfel încât toată această subrețea publică să fie rețeaua mea VPN! În timp ce exemplul OpenVPN pare artificial, WireGuard este mult mai probabil să fie configurat așa. De exemplu, noua soluție de spațiu de nume permite wireguard să fie singura interfață din sistem. Dacă există o cerință ca sistemul să aibă direct un IP public (nu voi discuta despre niciun motiv pentru care ar putea proveni această cerință), este inevitabil să ajungeți să utilizați IP-uri publice în interiorul VPN-ului! Cel mai probabil, fără nici un NAT pentru ei.

Alexis avatar
drapel in
Mulțumesc pentru răspunsul lung. NAT și NAPT au definiții, nu le interpretez greșit. Nu am vorbit niciodată despre IP-uri publice/private. Nu am etichetat wireguard pentru că, așa cum ați spus, nu contează ce controlează interfața. Un răspuns acceptabil îmi spune că **sursa NAT** a netfilter face de fapt **NAPT/PAT** în același timp. Asta este tot ceea ce mi-a ratat, am crezut că trebuie să îi spunem explicit netfilterului că vrem **de asemenea** traducerea portului în combinație cu NAT simplu.
Nikita Kipriyanov avatar
drapel za
De ce crezi că definiția pe care o întâlnești este corectă sau că nu ar putea exista o altă definiție? NAT ar putea fi definit astfel încât să includă și traducerea portului, iar *aceasta* definiție este folosită în Linux, și nu numai în Linux. De fapt, versiunea „strict” este destul de nepractică, deoarece utilizarea predominantă a NAT în zilele noastre este aceea de a permite multor mașini să acceseze Internet folosind o singură adresă IP publică, iar aceasta *necesită* traducerea portului și pentru motivul pe care l-am menționat în răspunsul meu. Deci, în scopuri practice, este mai înțelept să luăm o definiție a NAT care *include* traducerea portului.
Alexis avatar
drapel in
**rfc2663**:`Network Address Translation este o metodă prin care **adresele IP** sunt mapate de la un domeniu de adrese la altul, oferind rutare transparentă către gazdele finale.` Tocmai am citit definiția și nu include NAPT . Cu toate acestea, aveți dreptate din punct de vedere practic, este mai înțelept ca toți documentele/persoanele care menționează NAT să includă și în mod explicit PAT în definiția lor.
Alexis avatar
drapel in
De fapt, conform definiției, Linux și toate sunt greșite și toți ar trebui să folosească NAPT în loc de NAT...într-o lume în care oamenii folosesc termenii corecti.
Nikita Kipriyanov avatar
drapel za
Nu tu sau RFC definești vocabularul corect. Limba este o fiară vie asupra căreia se pare că nu avem absolut niciun control ;) Singurul lucru valabil aici este un consens public.
Alexis avatar
drapel in
De acord, în acest caz trebuie documentat sau menționat mai larg. Foarte rare sunt mențiunile de traducere a porturilor în legătură cu NAT doc/blog/tutoriale/orice pagină. De aici intrebarea mea.
TooTea avatar
drapel in
@Alexis „NAT” este doar termenul generic standard al industriei pentru orice fel de traducere de rețea și port. Dacă nu scrieți un RFC, nu trebuie să faceți o distincție explicită între NAT, NAPT și PAT. (Veți vedea, de asemenea, că oamenii vorbesc despre „NAT cu con complet” și „NAT simetric” și altele asemenea.)
Puncte:6
drapel gr

Dacă destinația își poate direcționa traficul către sursă, nu este necesar niciun NAT sau PAT.

De exemplu, nu este necesar NAT/PAT dacă clienții VPN din 10.8.0.0/24 doresc să vorbească cu dispozitivele dumneavoastră LAN în 192.168.1.0/24, atâta timp cât dispozitivele implicate pot ruta către cealaltă rețea (prin gateway-ul lor). ).

Când sursa se află într-o rețea rfc1918 (IP privată) și destinația este un IP public, deoarece rețelele rfc1918 nu sunt rutabile prin Internet, este necesar un NAT pentru a înlocui IP-ul privat cu IP-ul public. Aceasta este traducerea adresei sursă. Această lucrare poate fi făcută de un SNAT, nu de un PAT.

În plus, vă înșelați presupunând că SNAT/MASQUERADE nu schimbă porturile sursă.

Opțiunea --to-source este folosită pentru a specifica ce sursă ar trebui să utilizeze pachetul. Această opțiune, în cel mai simplu mod, necesită o adresă IP pe care dorim să o folosim pentru adresa IP sursă din antetul IP. Dacă dorim să echilibrăm mai multe adrese IP, putem folosi o serie de adrese IP, separate printr-o cratimă. Numerele IP --to--source ar putea fi atunci, de exemplu, ceva ca în exemplul de mai sus: 194.236.50.155-194.236.50.160. IP-ul sursă pentru fiecare flux pe care îl deschidem ar fi apoi alocat aleatoriu din acestea și un singur flux ar folosi întotdeauna aceeași adresă IP pentru toate pachetele din acel flux. De asemenea, putem specifica o gamă de porturi care urmează să fie utilizate de SNAT. Toate porturile sursă ar fi apoi limitate la porturile specificate. Bitul de port al regulii ar arăta ca în exemplul de mai sus, :1024-32000. Acest lucru este valabil numai dacă -p tcp sau -p udp a fost specificat undeva în potrivirea regulii în cauză. iptables va încerca întotdeauna să evite modificarea porturilor, dacă este posibil, dar dacă două gazde încearcă să folosească aceleași porturi, iptables va mapa unul dintre ele la alt port. Dacă nu este specificat niciun interval de porturi, atunci dacă sunt necesare, toate porturile sursă sub 512 vor fi mapate la alte porturi sub 512. Cele dintre porturile sursă 512 și 1023 vor fi mapate la porturile sub 1024. Toate celelalte porturi vor fi mapate la 1024 sau mai sus.După cum sa menționat anterior, iptables va încerca întotdeauna să mențină porturile sursă utilizate de stația de lucru care realizează conexiunea. Rețineți că acest lucru nu are nicio legătură cu porturile de destinație, așa că dacă un client încearcă să ia contact cu un server HTTP din afara firewall-ului, acesta nu va fi mapat la portul de control FTP.

https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#SNATTARGET

Rețineți că, dacă dispozitivul dvs. dorește să ajungă la un server la distanță pe un anumit port de destinație, există șanse ca sistemul de operare să fi atribuit deja un port sursă aleatoriu peste 1024. Atingerea unui server HTTPS la distanță pe portul 443 nu implică faptul că portul sursă este 443.

Alexis avatar
drapel in
Fără a adăuga rute statice în gateway sau în toate nodurile rețelei locale, acestea nu vor putea direcționa înapoi pachetele către subrețeaua VPN. Este necesar un NAT/NAPT.
Alexis avatar
drapel in
Nu sunt de acord cu `Această lucrare poate fi făcută de un SNAT, nu de un PAT`, un NAPT este necesar dacă există mai multe computere care folosesc același IP public.
Alexis avatar
drapel in
Mulțumesc pentru link, nu este un document oficial al iptables și asta e problema mea. Dacă într-adevăr se comportă așa pentru o regulă NAT, este împotriva rfc. Nu aș vrea ca iptables să facă ceea ce nu am cerut (alterând stratul 4).Aveți vreun **document oficial** care afirmă același lucru? netfilter, iptables sau nftables? De asemenea, nu amestecați termenul SNAT care descrie un concept cu numele unei ținte în iptables. Conform definiției sale, `SNAT/MASQUERADE` **NU** schimbă stratul 4. Dacă `iptables` permite să facă PAT/NAPT pe așa-numita țintă SNAT, asta este diferit.
drapel gr
Da, PAT este necesar, dar această sarcină este gestionată de ținta SNAT a iptables (sau MASQUERADE, care este practic SNAT). Acesta este motivul pentru care SNAT (sau MASQUERADE) lui iptables este suficient, nu trebuie să faceți în mod explicit PAT. SNAT face traducerea porturilor, așa cum se menționează în documentația neoficială, dar este confirmată de documentația oficială a netfilter. Consultați secțiunea " 6.3.4. Maparea implicită a portului sursă". https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.txt
Alexis avatar
drapel in
Mulțumiri. Bună captură, voi considera că este încă valabilă pentru nuclee>2.4. `SNAT/MASQUERADE` nu ar trebui să facă implicit traducerea portului. Cred că este mai degrabă o decizie a netfilter de a combina ambele. (după cum este specificat în rfc2663) Mi-aș fi dorit să fi putut fi explicat sau detaliat undeva. Voi fi atent cu alte sisteme.
ilkkachu avatar
drapel us
@Alexis, TBH, ești puțin prost. [Pagina de manual `iptables`](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) spune că `SNAT` face traducerea portului și că `MASQUERADE` este similar. Și RFC-ul la care v-ați conectat nici măcar nu menționează niciunul dintre acești doi termeni. Deci, este documentat să facă ceea ce face, iar RFC nici măcar nu folosește aceiași termeni, deci nu este nici măcar un sens supraîncărcat. Nicio problemă acolo. Dacă doriți doar traducerea adresei, atunci va trebui să utilizați o altă funcționalitate. `NETMAP` pare să fie unul, dar nu l-am folosit.
Alexis avatar
drapel in
@ilkkachu păstrează prostiile pentru tine, nu sunt prietenul tău.Pagina de manual pe care ați conectat-o ​​nu indică că face traducere automată a portului pentru `SNAT` sau `MASQUERADE`, doar opțiunile pe care le putem interpreta ca **opțional** indicând o caracteristică care este **în principal/99%** utilizată pentru explicit * *port forwarding**.
ilkkachu avatar
drapel us
@Alexis, nu-i așa? Pentru SNAT: „--to-source [...] Dacă nu este specificat niciun interval de porturi, atunci porturile sursă sub 512 vor fi mapate către alte porturi sub 512: cei între 512 și 1023 inclusiv vor fi mapate la porturi sub 1024, iar alte porturi vor fi mapate la 1024 sau mai sus. Acolo unde este posibil, nicio modificare a porturilor nu se va face apar." pentru MASQUERADE: "--to-ports port[-port] Aceasta specifică o gamă de porturi sursă de utilizat, suprascriind euristica implicită de selecție a portului sursă SNAT (vezi de mai sus)."
ilkkachu avatar
drapel us
@Alexis și nu am spus niciodată că ești așa. Doar că se pare că aveți niște așteptări care pur și simplu nu se aplică și că RFC-ul la care vă referiți nici măcar nu vă sprijină în întrebarea de denumire. Băieții de la Linux ajung să-și numească lucrurile cum le place și, după ani și ani în care a fost așa cum este, nu este probabil să le schimbe. Deci, practic, poți alege dacă vrei să lupți împotriva morilor de vânt (ceea ce, IMO, este puțin prostesc), sau să o accepți așa cum este. Dacă credeți că documentația nu este suficient de clară, ați putea desigur să le trimiteți un raport de eroare pentru a clarifica asta?

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.