NAT pe serverul VPN sau pe router? Ambele pot funcționa

Marcarea unei conexiuni ca rută implicită pe un laptop este pasul pe care toți îl țin minte, și exact acela nu schimbă nimic la gateway. Clientul trimite acum cererile de internet în tunel; dacă acestea părăsesc clădirea depinde de transmiterea mai departe, de un punct de traducere și de o cale de întoarcere care ajunge la adresa privată a clientului. Două aranjamente pot furniza toate trei, ele pun munca în locuri diferite, și ambele eșuează în același mod silențios când nimeni nu deține direcția răspunsului. Alegerea între ele este o întrebare despre cine ar trebui să vadă pool-ul de clienți.

Mitul: o rută de client construiește ieșirea

Tunelarea forțată este o politică pe partea clientului: decide că traficul merge la adaptorul VPN în locul celui fizic. Documentația Microsoft despre rutarea VPN descrie această separare și comportamentul forțat, și este o afirmație despre tabela de rute a clientului, nu despre regulile de transmitere ale serverului. Din punctul de vedere al clientului, tunelul este locul unde locuiește internetul; din punctul de vedere al gateway-ului, un pachet a sosit de la o adresă de care nimeni mai sus nu a auzit vreodată. Niciuna dintre părți nu este configurată greșit de una singură, și de aceea defecțiunea arată ca un server stricat pentru persoana de lângă laptop.

Această nepotrivire este întreaga problemă pe care o rezolvă restul articolului. Ceva trebuie să facă adresa privată a clientului returnabilă, iar alegerea este unde.

Desenați mai întâi calea de întoarcere

Scrieți calea cu adrese reale înainte de a atinge vreo setare, și marcați pe ea cele două puncte de traducere candidate. Acest laborator folosește un pool VPN de 10.70.0.0/24 cu un client la 10.70.0.37, o adresă LAN a serverului 172.16.40.10, un router la 172.16.40.1 și o ieșire publică 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Serverul care deja navighează pe internet își demonstrează doar propria cale. Un pachet transmis în numele unui client este o decizie diferită, luată de politica de transmitere de pe aceeași mașină, și aceasta este cea care lipsește de obicei. Marcarea celor trei puncte de decizie pe diagramă ține conversația despre unul dintre ele pe rând.

Opțiunea A: traducere pe serverul VPN

Aici serverul traduce sursa clientului în propria adresă LAN înainte de a preda pachetul routerului, iar routerul aplică traducerea sa obișnuită la ieșire. La răspuns, maparea routerului restaurează adresa serverului, iar maparea serverului restaurează adresa clientului. Două traduceri cu stare în serie sunt normale și fezabile, cu condiția ca ambele să fie înregistrate; routerul nu are niciodată nevoie de o rută către pool, și acesta este farmecul acestui aranjament.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Folosiți aceste citiri pentru a vedea ce are deja serverul în loc să presupuneți că există un NAT. O regulă masquerade din Linux copiată dintr-un blog nu este o configurație Windows, iar o permisiune în firewall-ul gazdei pentru ascultătorul VPN nu este aceeași politică precum permisiunea de a transmite mai departe cererea unui client. Confirmați rolul de transmitere al serverului din propria sa interfață de administrare, apoi priviți traducerea separat, pentru că cele două sunt adesea activate de părți diferite ale unei implementări.

Opțiunea B: aduceți pool-ul la router

În al doilea aranjament serverul transmite adevărata adresă sursă a clientului, iar routerul o traduce. Asta menține pool-ul de clienți vizibil la margine, ceea ce ajută dacă routerul este locul unde trăiesc politica de trafic, jurnalizarea sau inspecția. Înseamnă de asemenea că routerul are nevoie de o rută de întoarcere pentru 10.70.0.0/24 care indică spre 172.16.40.10, plus o politică de internet care include efectiv acel prefix; o regulă scrisă pentru subrețeaua LAN nu se extinde în tăcere la pool.

Alegeți această opțiune când dispozitivul de margine este proprietarul prevăzut al politicii și poate accepta un alt prefix în tabelele sale de rutare și traducere. Alegeți traducerea pe partea serverului când pool-ul trebuie să rămână invizibil mai sus și routerul nu este administrat de aceeași echipă. Niciuna dintre opțiuni nu este implicată de vreo casetă de selectare de pe client, și niciuna nu este mai sigură în general; ele pun vizibilitatea și mentenanța în locuri diferite.

Faceți explicite DNS, IPv6 și acceptarea

Traducerea adreselor nu repară rezolvarea numelor. Clientul poate folosi un resolver livrat cu profilul VPN, un resolver privat pentru anumite spații de nume sau unul public aprobat, iar un resolver inaccesibil sub acea politică va continua să eșueze după ce rutarea funcționează. Testați un nume și o adresă separat, pentru ca cele două defecțiuni să nu se contopească niciodată într-un singur raport.

IPv6 are nevoie de propriul paragraf în proiectare. O traducere IPv4 funcțională nu spune nimic despre dacă clienții IPv6 au rută, o sursă publică validă sau o politică ce îi blochează când tunelul cade. A lăsa asta nespus înseamnă că jumătate dintre clienți ocolesc gateway-ul în tăcere în timp ce cealaltă jumătate funcționează.

Pentru acceptare, urmăriți o cerere de client permisă și răspunsul ei prin ambele granițe, și notați ce adresă ar trebui să vadă fiecare graniță în acel moment. Acea înregistrare este ceea ce face următoarea schimbare de pool o editare de cinci minute în loc de o dezbatere despre cine deține ruta de întoarcere lipsă. Păstrați înregistrarea lângă profilul clientului și nu într-un tichet, deoarece profilul este ceea ce va găsi primul următorul inginer.