Ar trebui să aplicați SNAT pe o redirecționare de port către o subrețea VPN?

Redirecționarea unui port către o gazdă care stă în spatele clientului VPN propriu al routerului eșuează într-un mod care pare o problemă de firewall, pentru că cererea ajunge clar. Serviciul înregistrează o conexiune, clientul așteaptă și nimic nu se întoarce. Traducerea destinației și-a făcut treaba; pachetul de întoarcere este partea care a dispărut. O singură regulă NAT de sursă selectivă pe router remediază asta, iar partea interesantă este să decideți cât de îngustă poate fi regula.

De ce răspunsul ia alt drum

Redirecționarea de port rescrie unde merge un pachet, niciodată de unde a venit. Adresa clientului de internet rămâne în câmpul sursă pe tot parcursul tunelului, așa că serviciul îndepărtat vede un străin și răspunde în singurul mod pe care îl știe: prin propriul gateway implicit. Acel gateway este concentratorul VPN din partea cealaltă, care nu are nicio rută înapoi către o adresă publică arbitrară.

Urmăriți o captură pe interfața tunelului și asimetria este evidentă: pachete de cerere spre exterior, nimic spre interior. Lanțul de redirecționare a permis fluxul și tunelul l-a transportat, deci pierderea are loc după ce gazda îndepărtată a ales deja o cale de întoarcere.

O regulă de sursă suficient de îngustă pentru a avea încredere

Faceți routerul sursa la care răspunde gazda îndepărtată. În această configurație adresa WAN este 203.0.113.24, LAN-ul este 192.168.88.0/24, adresa tunelului routerului este 172.20.5.1, iar serviciul răspunde pe 172.20.5.40:8443. Regula de mai jos se potrivește pachetului după traducerea destinației, de aceea numește adresa tradusă, nu pe cea publică. Nimic din ea nu depinde de adresa clientului, și exact acesta este ideea.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Fiecare potrivire din acea linie există pentru a păstra rescrierea locală la un singur serviciu pe un singur tunel. Scoateți interfața sau portul și rescrieți mai mult trafic decât cere problema, și așa o corecție țintită devine un mister pentru următoarea persoană.

Când o mască generală este alegerea onestă

Dacă routerul redirecționează multe servicii în același subrețea VPN, regula pe serviciu devine o listă pe care nimeni nu o întreține. Mascarea a tot ce iese din interfața tunelului este mai simplă și previzibilă, cu prețul ascunderii clientului original de fiecare gazdă din partea cealaltă. Alegeți-o când jurnalele de acolo nu sunt folosite pentru atribuire; păstrați regula îngustă când sunt.

Cele două opțiuni eșuează și diferit. O regulă îngustă lipsă strică un serviciu; o mască largă care se potrivește prea mult poate rescrie în tăcere trafic care funcționa deja, inclusiv conexiunile de ieșire ale routerului însuși.

Verificați contoarele înainte de publicare

Regulile care nu se potrivesc niciodată arată identic cu regulile care funcționează până când numărați pachetele. Recitiți tabelul cu contoare de octeți înainte ca vreun client să se conecteze, apoi conectați-vă dintr-o rețea care nu este LAN și recitiți-l. Două citiri sunt ceea ce transformă o presupunere într-un fapt. Publicați redirecționarea doar după ce a doua se mișcă.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Un contor zero pe regula de sursă după o conexiune reală înseamnă că potrivirea este greșită, de obicei pentru că destinația sau portul nu corespund pachetului după traducere. Dacă contorul crește, dar clientul încă expiră, calea de întoarcere este reparată și altceva aruncă răspunsul, așa că uitați-vă apoi la politica de redirecționare din partea cealaltă. Accesul în ac din interiorul LAN este o problemă separată și are nevoie de propria regulă, nu de o versiune mai largă a acesteia.