Publicarea unui serviciu LAN pe adresa proprie a gateway-ului VPN

Prezentarea unui dispozitiv LAN pe una dintre adresele de tunel proprii ale gateway-ului necesită o singură linie de NAT. Conexiunea eșuează totuși, pentru că dispozitivul care răspunde nu știe că adresa clientului este accesibilă prin acel gateway. Urmați pachetul de la client spre interior, apoi urmați răspunsul înapoi spre exterior, și jumătatea lipsă devine evidentă.

Începeți din perspectiva clientului

Clientul din acest exemplu se află în pool-ul VPN 10.62.0.0/24 și se conectează la 10.62.0.1 pe portul 8080. Adresa aceea aparține gateway-ului însuși, așa că pachetul ajunge în nucleul gateway-ului, nu la alt partener. În spatele gateway-ului, LAN-ul este 172.21.4.0/24. Gateway-ul deține 172.21.4.10, iar dispozitivul care servește efectiv HTTP este 172.21.4.40.

O adresă care aparține altui partener VPN nu este interschimbabilă cu adresa de serviciu a gateway-ului. Dacă clientul se conectează la adresa unui partener, nicio regulă a gateway-ului nu este implicată, iar întreaga parcurgere este cazul greșit.

Delimitați intenționat traducerea destinației

Versiunea îngustă prezintă un singur port și rescrie doar destinația. Pachetul își păstrează protocolul și sursa, iar asta face restul parcursului interesant.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

O regulă fără criterii de protocol și port este versiunea largă: păstrează orice port ales de client și schimbă doar adresa. Acest lucru este legitim când se intenționează prezentarea întregului host și greșit când intenția era un singur serviciu. Citiți regula înapoi și confirmați numele interfeței. O regulă DNAT pe interfața greșită nu se potrivește cu nimic, ceea ce produce același timp de așteptare ca o regulă lipsă și irosește o oră uitându-vă la dispozitiv.

Lăsați granița de redirecționare să fie de acord

Traducerea schimbă antetul, dar nu acordă permisiune. Cu o politică implicită de eliminare, fluxul redirecționat are nevoie de propria acceptare, iar direcția de retur are nevoie de regula conexiunii stabilite pe care politica dumneavoastră probabil o are deja.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

O acceptare necondiționată pentru fiecare flux DNAT este mai largă decât acest proiect și va permite și mapări adăugate mai târziu de altcineva. Numiți destinația și portul, și lăsați restul închis. Dacă contoarele regulii de redirecționare rămân la zero în timp ce contoarele NAT cresc, pachetul este eliminat înainte de regula dumneavoastră. Citiți ordinea lanțurilor în loc să adăugați o a doua copie.

Dispozitivul trebuie să răspundă într-un fel

După traducere, dispozitivul vede o sursă în 10.62.0.0/24. Răspunsul merge la gateway-ul său implicit, care este routerul LAN, nu gateway-ul VPN, dacă ceva nu îi spune altfel. Două aranjamente remediează asta și nu sunt echivalente. O rută pe dispozitiv sau pe routerul LAN trimite 10.62.0.0/24 la 172.21.4.10 păstrând sursa clientului. O traducere de sursă limitată ascunde clientul în spatele adresei LAN a gateway-ului.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Alegeți după ce are nevoie serviciul. Politica pe client și jurnalele semnificative vor forma rutată; un dispozitiv căruia nu i se poate da o rută, sau un serviciu care pur și simplu trebuie să vadă o adresă LAN, indică forma tradusă. Nu recurgeți la o regulă masquerade globală pentru ca un singur răspuns să funcționeze. Ascunde fiecare client de fiecare destinație și rupe în liniște politicile care depind de adresele sursă.

Nu testați de pe gateway-ul însuși

O cerere generată pe gateway către 10.62.0.1 iese prin lanțul OUTPUT, nu prin PREROUTING-ul de intrare. Eșecul sau succesul ei nu spune nimic despre regula orientată spre client, și așa ajung oamenii să concluzioneze că o regulă funcțională este stricată.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Rulați o cerere reală de client și citiți ambele. Intrarea conntrack arată traducerea aplicată, iar capturile arată dacă cererea a trecut în LAN și dacă a venit un răspuns înapoi spre tunel. Folosiți o conexiune nouă după modificarea regulilor, pentru că starea existentă își păstrează maparea anterioară și va continua să eșueze în felul vechi. Apoi confirmați întreaga conversație: adresa dispozitivului, permisiunea de redirecționare și ruta răspunsului descriu toate același flux.