Clienți din aval în spatele unui VPN din amonte: rută sau NAT?

Un gateway rulează WireGuard pentru dispozitivele tale și un client OpenVPN către rețeaua altcuiva. Transmiterea între cele două interfețe interne funcționează, și e ușor să concluzionezi că subrețeaua din aval face acum parte din serviciul din amonte. Nu face. O rută obținută de client îi spune gateway-ului tău unde să trimită cererile; nu spune nimic despre cum rețeaua îndepărtată returnează traficul către dispozitive de care nu a auzit niciodată. Alege un model de retur pe care serviciul din amonte îl susține cu adevărat înainte de a adăuga o singură regulă.

Decide modelul de retur înainte de a atinge rutarea

În acest ghid, clienții din aval folosesc 10.90.0.0/24, adresa tunelului din amonte atribuită gateway-ului este 10.80.0.6, iar resursa îndepărtată aprobată este 172.20.0.30. Două modele se potrivesc acestei forme: păstrează sursa din aval și fă partea îndepărtată să o ruteze, sau traduce sursa în adresa tunelului propriu al gateway-ului. Tot ce urmează acestei decizii este mecanic, iar decizia în sine are nevoie de proprietarul serviciului. Una dintre rândurile de mai sus este un acord de rutare cu partea îndepărtată; cealaltă este o schimbare locală de politică pe care o poți face singur. Confundarea celor două este ce transformă o schimbare de zece minute într-o negociere.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Alege un rând și ține-te de el. Rândurile sunt alternative, nu pași, iar amestecarea lor produce un design pe care nimeni nu îl poate explica la revizuire.

Păstrarea sursei prin rutare

Partea îndepărtată primește o cerere de la o adresă din aval, așa că are nevoie de o rută susținută și de proprietatea peer-ului pentru acea subrețea, plus autorizarea de a o accepta. Sunt setări la distanță, și nicio rută Linux locală nu le creează. Cere-le explicit și în scris, cu prefixul și cu peer-ul tunelului care o va transporta, și așteaptă-te ca răspunsul să depindă de faptul că serviciul susține sau nu aranjamente site-to-site.

Dacă răspunsul este da, configurația locală este mică: transmitere activată, allowed-ips ale peer-ului WireGuard care acoperă intervalul din aval, și o politică de firewall care permite traversarea în ambele sensuri.

Traducere de sursă deliberată

Dacă serviciul returnează traficul doar la adresa clientului conectat, traduce sursa în acea adresă la ieșire și păstrează starea conntrack care o inversează pentru răspunsuri. Limitează regula la sursele din aval dorite, la destinațiile îndepărtate dorite și la interfața din amonte. O regulă care traduce tot ce iese din fiecare interfață este o politică mult mai mare decât această cerință și te va surprinde mai târziu.

IPv6 are nevoie de propriul design; copierea unei linii masquerade IPv4 nu este arhitectură. Testează calea tradusă cu o conexiune nouă, nu cu una din cache.

Calea locală de date tot trebuie să funcționeze

Traducerea nu elimină munca locală: gateway-ul are în continuare nevoie de o rută către destinațiile din aval, de proprietatea corectă a sursei peer-ului WireGuard, de transmitere activată și de o politică de firewall îngustă între interfețe. O cerere generată pe gateway-ul însuși nu exersează niciuna dintre aceste permisiuni, de aceea testele locale pe gateway trec, iar dispozitivele din aval tot eșuează.

Testează de pe un dispozitiv real din aval, nu de pe gateway. Adresa sursă este tot rostul exercițiului.

O singură sursă înseamnă o singură identitate de sesiune

Serviciul îndepărtat vede sesiunea autentificată a gateway-ului și adresa ei tradusă, nu o autentificare independentă pentru fiecare dispozitiv din aval. Ține explicite permisiunile pe dispozitiv și identitățile aplicațiilor, și confirmă cu proprietarul serviciului că un gateway care acționează pentru mai multe dispozitive este măcar permis. Traducerea nu este o modalitate de a ocoli cerința de înregistrare pe dispozitiv; dacă serviciul cere ca fiecare dispozitiv să se înregistreze, folosește acel model sau negociază un aranjament site-to-site.

Scrie acea confirmare în runbook lângă regulă, pentru că următorul revizor va întreba dacă designul a fost aprobat sau doar convenabil.

Definește starea de deconectare, apoi testează trei cereri

Decide ce se întâmplă când tunelul din amonte cade. Traficul îndepărtat autorizat nu ar trebui să urmeze în tăcere o cale WAN obișnuită de rezervă acolo unde acest lucru este interzis, așa că politica de firewall care permite traversarea trebuie și ea să eșueze închisă. Apoi testează trei cazuri de pe un dispozitiv real din aval: o cerere permisă care funcționează, o cerere nepermisă care eșuează, și o defecțiune în amonte care o oprește pe cea permisă.

Notează revenirea pe o singură linie pentru fiecare regulă, ca schimbarea să poată fi anulată fără a reconstrui intenția.