NAT në serverin VPN apo në router? Të dyja mund të funksionojnë

Shënimi i një lidhjeje si rrugë e parazgjedhur në një laptop është hapi që të gjithë e mbajnë mend, dhe është pikërisht ai që nuk ndryshon asgjë në portë. Klienti tani i dërgon kërkesat e internetit në tunel; nëse ato e lënë ndërtesën varet nga përcjellja, një pikë përkthimi dhe një rrugë kthimi që arrin adresën private të klientit. Dy rregullime mund t'i ofrojnë të tria, ato e vendosin punën në vende të ndryshme, dhe të dyja dështojnë në të njëjtën mënyrë të heshtur kur askush nuk e zotëron drejtimin e përgjigjes. Zgjedhja mes tyre është një pyetje se kush duhet ta shohë pishinën e klientëve.

Miti: një rrugë klienti ndërton daljen

Tunelimi i detyruar është një politikë në anën e klientit: vendos që trafiku të shkojë te përshtatësi VPN në vend të atij fizik. Dokumentacioni i Microsoft për rrugëtimin VPN përshkruan atë ndarje dhe sjelljen e detyruar, dhe është një pohim për tabelën e rrugëve të klientit, jo për rregullat e përcjelljes së serverit. Nga këndvështrimi i klientit tuneli është vendi ku jeton interneti; nga këndvështrimi i portës mbërriti një paketë nga një adresë për të cilën askush më lart nuk ka dëgjuar ndonjëherë. Asnjëra anë nuk është e konfiguruar gabimisht vetëm për vete, dhe për këtë arsye dështimi i duket personit pranë laptopit si një server i prishur.

Ai mospërputhje është i gjithë problemi që zgjidh pjesa tjetër e këtij artikulli. Diçka duhet ta bëjë adresën private të klientit të kthyeshme, dhe zgjedhja është ku.

Fillimisht vizatoni rrugën e kthimit

Shkruajeni rrugën me adresa reale përpara se të prekni ndonjë cilësim, dhe shënoni mbi të dy pikat e mundshme të përkthimit. Ky laborator përdor një pishinë VPN prej 10.70.0.0/24 me një klient në 10.70.0.37, një adresë LAN të serverit 172.16.40.10, një router në 172.16.40.1 dhe një dalje publike 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?)

Serveri që tashmë shfleton internetin provon vetëm rrugën e vet. Një paketë e përcjellë në emër të një klienti është një vendim tjetër, i marrë nga politika e përcjelljes në të njëjtën makinë, dhe është pikërisht ai që zakonisht mungon. Shënimi i tre pikave të vendimit në diagram e mban bisedën për njërën prej tyre në një herë.

Opsioni A: përkthe në serverin VPN

Këtu serveri e përkthen burimin e klientit në adresën e tij LAN përpara se t'i dorëzojë paketën routerit, dhe routeri zbaton përkthimin e tij të zakonshëm në dalje. Në përgjigje, hartëzimi i routerit rikthen adresën e serverit dhe hartëzimi i serverit rikthen adresën e klientit. Dy përkthime me gjendje në seri janë normale dhe të zbatueshme, me kusht që të dyja të regjistrohen; routeri nuk ka nevojë kurrë për një rrugë drejt pishinës, dhe ky është tërheqja e këtij rregullimi.

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

Përdorini këto lexime për të parë çfarë ka tashmë serveri në vend që të supozoni se ekziston një NAT. Një rregull masquerade i Linux-it i kopjuar nga një blog nuk është një konfigurim i Windows, dhe një leje në murin e zjarrit të hostit për dëgjuesin VPN nuk është e njëjta politikë si leja për të përcjellë më tej kërkesën e një klienti. Konfirmoni rolin e përcjelljes së serverit nga sipërfaqja e tij e administrimit, dhe pastaj shikoni përkthimin veçmas, sepse të dyja shpesh aktivizohen nga pjesë të ndryshme të një vendosjeje.

Opsioni B: ço pishinën te routeri

Në rregullimin e dytë serveri përcjell adresën e vërtetë të burimit të klientit, dhe routeri e përkthen atë. Kjo e mban pishinën e klientëve të dukshme në skaj, gjë që ndihmon nëse routeri është vendi ku jetojnë politika e trafikut, regjistrimi ose inspektimi. Do të thotë gjithashtu se routeri ka nevojë për një rrugë kthimi për 10.70.0.0/24 që tregon drejt 172.16.40.10, plus një politikë interneti që e përfshin vërtet atë parashtesë; një rregull i shkruar për nënrrjetin LAN nuk shtrihet në heshtje te pishina.

Zgjidhni këtë kur pajisja e skajit është pronari i synuar i politikës dhe mund të pranojë një parashtesë tjetër në tabelat e tij të rrugëtimit dhe përkthimit. Zgjidhni përkthimin në anën e serverit kur pishina duhet të mbetet e padukshme më lart dhe routeri nuk administrohet nga i njëjti ekip. Asnjë opsion nuk nënkuptohet nga asnjë kuti kontrolli në klient, dhe asnjëri nuk është më i sigurt në përgjithësi; ata e vendosin dukshmërinë dhe mirëmbajtjen në vende të ndryshme.

Bëni DNS, IPv6 dhe pranimin të qartë

Përkthimi i adresave nuk e rregullon zgjidhjen e emrave. Klienti mund të përdorë një zgjidhës të dhënë me profilin VPN, një zgjidhës privat për hapësira emrash të caktuara, ose një publik të miratuar, dhe një zgjidhës i paarritshëm sipas asaj politike do të vazhdojë të dështojë pasi rrugëtimi të funksionojë. Testoni një emër dhe një adresë veçmas, që dy dështimet të mos bashkohen kurrë në një raport.

IPv6 ka nevojë për paragrafin e vet në projektim. Një përkthim IPv4 që funksionon nuk thotë asgjë për atë nëse klientët IPv6 kanë rrugë, një burim publik të vlefshëm ose një politikë që i bllokon kur tuneli bie. Ta lëshë këtë të pashprehur do të thotë që gjysma e klientëve e anashkalojnë portën në heshtje ndërsa gjysma tjetër funksionon.

Për pranimin, ndiqni një kërkesë klienti të lejuar dhe përgjigjen e saj përgjatë dy kufijve, dhe shkruani cilën adresë duhet të shohë çdo kufi në atë moment. Ai regjistrim është ai që e bën ndryshimin e radhës të pishinës një redaktim pesë minutash në vend të një debati për atë se kush e zotëron rrugën e kthimit që mungon. Mbajeni regjistrimin me profilin e klientit dhe jo në një tiketë, sepse profili është ai që inxhinieri i radhës do të gjejë i pari.