NAT na strežniku VPN ali na usmerjevalniku? Obe možnosti lahko delujeta

Označiti povezavo kot privzeto pot na prenosniku je korak, ki se ga vsi spomnijo, in prav ta na prehodu ne spremeni ničesar. Odjemalec zdaj pošilja internetne zahteve v tunel; ali zapustijo zgradbo, je odvisno od posredovanja, točke prevajanja in povratne poti, ki doseže zasebni naslov odjemalca. Dve ureditvi lahko zagotovita vse tri, delo postavljata na različna mesta, in obe odpovedujeta na enak tih način, ko nihče ne skrbi za smer odgovora. Izbira med njima je vprašanje, kdo naj vidi skupino odjemalcev.

Mit: pot odjemalca zgradi izhod

Prisilno tuneliranje je politika na strani odjemalca: odloči, da promet gre na vmesnik VPN namesto na fizičnega. Dokumentacija Microsofta o usmerjanju VPN opisuje to razdelitev in prisilno vedenje, in to je trditev o usmerjevalni tabeli odjemalca, ne o pravilih posredovanja strežnika. Z vidika odjemalca je tunel kraj, kjer živi internet; z vidika prehoda je prišel paket z naslova, o katerem ni nihče višje nikoli slišal. Nobena stran ni sama po sebi napačno nastavljena, in zato se okvara osebi ob prenosniku zdi kot pokvarjen strežnik.

To neskladje je ves problem, ki ga rešuje preostanek članka. Nekaj mora narediti zasebni naslov odjemalca povratno dosegljiv, izbira pa je kje.

Najprej narišite povratno pot

Zapišite pot z resničnimi naslovi, preden se dotaknete katere koli nastavitve, in na njej označite dve možni točki prevajanja. To laboratorij uporablja bazen VPN 10.70.0.0/24 z enim odjemalcem na 10.70.0.37, naslovom LAN strežnika 172.16.40.10, usmerjevalnikom na 172.16.40.1 in javnim izhodom 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?)

Strežnik, ki že brska po internetu, dokazuje samo svojo pot. Paket, posredovan v imenu odjemalca, je druga odločitev, ki jo sprejme politika posredovanja na istem stroju, in običajno manjka prav ta. Označevanje treh odločitvenih točk na diagramu ohranja pogovor o eni od njih naenkrat.

Možnost A: prevajanje na strežniku VPN

Tu strežnik prevede vir odjemalca v svoj naslov LAN, preden paket izroči usmerjevalniku, usmerjevalnik pa na izhodu uporabi svoje običajno prevajanje. Na odgovoru preslikava usmerjevalnika obnovi naslov strežnika, preslikava strežnika pa obnovi naslov odjemalca. Dve stanje ohranjajoči prevajanji v zaporedju sta običajni in izvedljivi, če sta obe zabeleženi; usmerjevalnik nikoli ne potrebuje poti do bazena, in to je privlačnost te ureditve.

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

S temi branji poglejte, kaj strežnik že ima, namesto da bi predpostavljali, da je NAT na mestu. Pravilo masquerade v Linuxu, kopirano z bloga, ni konfiguracija Windows, in dovoljenje v požarnem zidu gostitelja za poslušalca VPN ni ista politika kot dovoljenje za posredovanje zahteve odjemalca naprej. Potrdite vlogo posredovanja strežnika v njegovem lastnem upravljalnem vmesniku, nato pa si prevajanje oglejte ločeno, ker oba pogosto omogočijo različni deli uvajanja.

Možnost B: prenesti bazen na usmerjevalnik

V drugi ureditvi strežnik posreduje pravi izvorni naslov odjemalca, usmerjevalnik pa ga prevede. To ohranja skupino odjemalcev vidno na robu, kar pomaga, če je usmerjevalnik kraj, kjer živijo prometna politika, beleženje ali pregledovanje. Pomeni tudi, da usmerjevalnik potrebuje povratno pot za 10.70.0.0/24, ki kaže na 172.16.40.10, poleg internetne politike, ki ta predpona res vključuje; pravilo, napisano za podomrežje LAN, se tiho ne razširi na bazen.

Izberite to, ko je robna naprava predvideni lastnik politike in lahko sprejme še eno predpono v svojih usmerjevalnih in prevajalnih tabelah. Izberite prevajanje na strani strežnika, ko mora bazen ostati neviden višje in usmerjevalnika ne upravlja ista ekipa. Nobene možnosti ne nakazuje nobeno potrditveno polje na odjemalcu in nobena ni na splošno varnejša; vidnost in vzdrževanje postavljata na različna mesta.

Naredite DNS, IPv6 in sprejem izrecne

Prevajanje naslovov ne popravi razreševanja imen. Odjemalec lahko uporabi razreševalnik, dobavljen s profilom VPN, zasebni razreševalnik za določene imenske prostore ali odobreni javni, in nedosegljiv razreševalnik pod to politiko bo še naprej odpovedoval, potem ko bo usmerjanje delovalo. Preizkusite ime in naslov ločeno, da se obe okvari nikoli ne združita v eno poročilo.

IPv6 potrebuje v zasnovi svoj odstavek. Delujoče prevajanje IPv4 ne pove ničesar o tem, ali imajo odjemalci IPv6 pot, veljaven javni vir ali politiko, ki jih blokira, ko tunel pade. Če tega ne izrazimo, polovica odjemalcev tiho obide prehod, medtem ko druga polovica deluje.

Za sprejem sledite eni dovoljeni zahtevi odjemalca in njenemu odgovoru čez obe meji ter zapišite, kateri naslov naj bi vsaka meja videla v tistem trenutku. Prav ta zapis naredi naslednjo spremembo bazena petminutno urejanje namesto prepira o tem, kdo ima manjkajočo povratno pot. Zapis hranite ob profilu odjemalca in ne v zahtevku, ker je profil tisto, kar bo naslednji inženir našel prvo.