NAT sur la VPN-servilo aŭ sur la enkursigilo? Ambaŭ povas funkcii

Marki konekton kiel la defaŭltan itineron sur tekkomputilo estas la paŝo, kiun ĉiuj memoras, kaj ĝi estas ĝuste tiu, kiu ŝanĝas nenion ĉe la pordego. La kliento nun sendas retpetojn en la tunelon; ĉu ili forlasos la konstruaĵon dependas de plusendado, tradukpunkto kaj revena vojo, kiu atingas la privatan adreson de la kliento. Du aranĝoj povas liveri ĉiujn tri, ili metas la laboron en malsamaj lokoj, kaj ambaŭ malsukcesas laŭ la sama silenta maniero kiam neniu posedas la respondon direkton. Elekti inter ili estas demando pri tio, kiu devus vidi la klientan basenon.

La mito: klienta itinero konstruas la eliron

Trudita tunelado estas politiko ĉe la klienta flanko: ĝi decidas, ke trafiko iras al la VPN-adaptilo anstataŭ al la fizika. La dokumentaro de Microsoft pri VPN-enkursigado priskribas tiun dividon kaj trudan konduton, kaj ĝi estas aserto pri la itinera tabelo de la kliento, ne pri la plusendaj reguloj de la servilo. El la vidpunkto de la kliento la tunelo estas kie loĝas la interreto; el la vidpunkto de la pordego paketo alvenis de adreso, pri kiu neniu pli supre iam aŭdis. Neniu flanko estas erare agordita izolite, kaj tial la fiasko aspektas kiel rompita servilo al la persono ĉe la tekkomputilo.

Tiu miskongruo estas la tuta problemo, kiun solvas la resto de ĉi tiu artikolo. Io devas igi la privatan adreson de la kliento revenebla, kaj la elekto estas kie.

Unue desegnu la revenan vojon

Skribu la vojon per realaj adresoj antaŭ ol tuŝi ajnan agordon, kaj marku sur ĝi la du eblajn tradukpunktojn. Ĉi tiu laboratorio uzas VPN-basenon 10.70.0.0/24 kun unu kliento ĉe 10.70.0.37, servilan LAN-adreson 172.16.40.10, enkursigilon ĉe 172.16.40.1 kaj publikan eliron 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?)

La servilo, kiu jam retumas, pruvas nur sian propran vojon. Paketo plusendita nome de kliento estas alia decido, farita de la plusenda politiko sur la sama maŝino, kaj ĝi estas tiu, kiu kutime mankas. Marki la tri decidpunktojn sur la diagramo tenas la konversacion pri unu el ili samtempe.

Opcio A: traduki sur la VPN-servilo

Ĉi tie la servilo tradukas la fonton de la kliento al sia propra LAN-adreso antaŭ ol transdoni la paketon al la enkursigilo, kaj la enkursigilo aplikas sian ordinaran tradukon survoje eksteren. Ĉe la respondo, la mapado de la enkursigilo restarigas la servilan adreson, kaj la mapado de la servilo restarigas la klientan adreson. Du statohavaj tradukoj sinsekve estas normalaj kaj fareblaj, kondiĉe ke ambaŭ estas registritaj; la enkursigilo neniam bezonas itineron al la baseno, kaj tio estas la allogo de ĉi tiu aranĝo.

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

Uzu ĉi tiujn legaĵojn por vidi, kion la servilo jam havas, anstataŭ supozi, ke NAT ekzistas. Linux-masquerade-regulo kopiita el blogo ne estas Windows-agordo, kaj permeso en la gastiga fajroŝirmilo por la VPN-aŭskultanto ne estas la sama politiko kiel permeso plusendi peton de kliento pluen. Konfirmu la plusendan rolon de la servilo el ĝia propra administra surfaco, poste rigardu la tradukon aparte, ĉar la du ofte estas ŝaltataj de malsamaj partoj de disfaldiĝo.

Opcio B: porti la basenon al la enkursigilo

En la dua aranĝo la servilo plusendas la veran fontadreson de la kliento, kaj la enkursigilo tradukas ĝin. Tio tenas la klientan basenon videbla ĉe la rando, kio helpas se la enkursigilo estas kie loĝas trafika politiko, protokolado aŭ inspektado. Ĝi ankaŭ signifas, ke la enkursigilo bezonas revenan itineron por 10.70.0.0/24 montrantan al 172.16.40.10, plus interretan politikon, kiu vere inkluzivas tiun prefikson; regulo skribita por la LAN-subreto ne etendiĝas silente al la baseno.

Elektu ĉi tion kiam la randa aparato estas la celita posedanto de la politiko kaj povas akcepti alian prefikson en siaj enkursigaj kaj tradukaj tabeloj. Elektu la servoflankan tradukon kiam la baseno devus resti nevidebla pli supre kaj la enkursigilon ne administras la sama teamo. Neniu opcio estas implicata de iu ajn markobutono sur la kliento, kaj neniu estas pli sekura ĝenerale; ili metas videblecon kaj prizorgadon en malsamaj lokoj.

Faru DNS, IPv6 kaj akcepton eksplicitaj

Adresa tradukado ne riparas nomrezolucion. La kliento povas uzi solvanton liveritan kun la VPN-profilo, privatan solvanton por specifaj nomspacoj, aŭ aprobitan publikan, kaj neatingebla solvanto sub tiu politiko daŭre malsukcesos post kiam la enkursigado funkcias. Testu nomon kaj adreson aparte, por ke la du fiaskoj neniam kunfandiĝu en unu raporton.

IPv6 bezonas sian propran alineon en la dezajno. Funkcianta IPv4-traduko diras nenion pri tio, ĉu IPv6-klientoj havas itineron, validan publikan fonton aŭ politikon, kiu blokas ilin kiam la tunelo falas. Lasi tion neeldirita signifas, ke duono de la klientoj silente preterpasas la pordegon dum la alia duono funkcias.

Por akcepto, sekvu unu permesitan klientan peton kaj ĝian respondon trans ambaŭ limoj, kaj notu, kiun adreson ĉiu limo devus vidi en tiu momento. Tiu registro estas tio, kio igas la sekvan basenan ŝanĝon kvinminuta redakto anstataŭ disputo pri tio, kiu posedas la mankan revenan itineron. Konservu la registron kun la klienta profilo anstataŭ en bileto, ĉar la profilo estas tio, kion la sekva inĝeniero trovos unue.