NAT VPN serverī vai maršrutētājā? Abi varianti var darboties

Savienojuma atzīmēšana par noklusējuma maršrutu klēpjdatorā ir solis, ko visi atceras, un tieši tas vārtejā neko nemaina. Klients tagad sūta interneta pieprasījumus tunelī; vai tie izies no ēkas, ir atkarīgs no pārsūtīšanas, tulkošanas punkta un atgriešanās ceļa, kas sasniedz klienta privāto adresi. Divi izkārtojumi var nodrošināt visus trīs, tie liek darbu dažādās vietās, un abi neizdodas vienādi klusi, kad neviens neatbild par atbildes virzienu. Izvēle starp tiem ir jautājums par to, kam vajadzētu redzēt klientu pūlu.

Mīts: klienta maršruts veido izeju

Piespiedu tunelēšana ir klienta puses politika: tā nosaka, ka trafiks iet uz VPN adapteri, nevis uz fizisko. Microsoft VPN maršrutēšanas dokumentācija apraksta šo sadalījumu un piespiedu uzvedību, un tas ir apgalvojums par klienta maršrutu tabulu, nevis par servera pārsūtīšanas noteikumiem. No klienta viedokļa tunelis ir vieta, kur dzīvo internets; no vārtejas viedokļa pakete ieradās no adreses, par kuru neviens augstāk nekad nav dzirdējis. Neviena puse atsevišķi nav nepareizi konfigurēta, un tāpēc kļūme cilvēkam pie klēpjdatora izskatās kā salauzts serveris.

Šī neatbilstība ir visa problēma, ko atrisina pārējā raksta daļa. Kaut kam ir jāpadara klienta privātā adrese atgriežama, un izvēle ir kur.

Vispirms uzzīmējiet atgriešanās ceļu

Pierakstiet ceļu ar reālām adresēm, pirms pieskaraties jebkuram iestatījumam, un atzīmējiet tajā divus iespējamos tulkošanas punktus. Šī laboratorija izmanto 10.70.0.0/24 VPN pūlu ar vienu klientu 10.70.0.37 adresē, servera LAN adresi 172.16.40.10, maršrutētāju 172.16.40.1 adresē un publisku izeju 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?)

Serveris, kas jau pārlūko internetu, pierāda tikai savu ceļu. Klienta vārdā pārsūtīta pakete ir cits lēmums, ko pieņem tās pašas mašīnas pārsūtīšanas politika, un parasti trūkst tieši tā. Trīs lēmumu punktu atzīmēšana diagrammā notur sarunu par vienu no tiem vienlaikus.

A variants: tulkot VPN serverī

Šeit serveris pārtulko klienta avotu savā LAN adresē, pirms nodod paketi maršrutētājam, un maršrutētājs izejas ceļā piemēro savu parasto tulkojumu. Atbildē maršrutētāja kartēšana atjauno servera adresi, un servera kartēšana atjauno klienta adresi. Divi tulkojumi ar stāvokli pēc kārtas ir normāli un īstenojami, ja abi tiek reģistrēti; maršrutētājam nekad nav vajadzīgs maršruts uz pūlu, un tas ir šī izkārtojuma pievilcība.

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

Izmantojiet šos nolasījumus, lai redzētu, kas serverim jau ir, tā vietā lai pieņemtu, ka NAT ir vietā. No emuāra nokopēts Linux masquerade noteikums nav Windows konfigurācija, un atļauja resursdatora ugunsmūrī VPN klausītājam nav tā pati politika kā atļauja pārsūtīt klienta pieprasījumu tālāk. Apstipriniet servera pārsūtīšanas lomu tā paša pārvaldības saskarnē, pēc tam aplūkojiet tulkojumu atsevišķi, jo abus bieži iespējo dažādas izvietošanas daļas.

B variants: pārvietot pūlu uz maršrutētāju

Otrajā izkārtojumā serveris pārsūta klienta īsto avota adresi, un maršrutētājs to pārtulko. Tas notur klientu pūlu redzamu malā, kas palīdz, ja maršrutētājs ir vieta, kur dzīvo trafika politika, reģistrēšana vai pārbaude. Tas arī nozīmē, ka maršrutētājam ir vajadzīgs atgriešanās maršruts 10.70.0.0/24, kas norāda uz 172.16.40.10, kā arī interneta politika, kas tiešām ietver šo prefiksu; noteikums, kas rakstīts LAN apakštīklam, klusi neattiecas uz pūlu.

Izvēlieties šo, ja malas ierīce ir paredzētais politikas īpašnieks un var pieņemt vēl vienu prefiksu savās maršrutēšanas un tulkošanas tabulās. Izvēlieties servera puses tulkojumu, ja pūlam jāpaliek neredzamam augstāk un maršrutētāju nepārvalda tā pati komanda. Nevienu variantu neparedz neviena izvēles rūtiņa klientā, un neviens nav vispārīgi drošāks; tie novieto redzamību un uzturēšanu dažādās vietās.

Padariet DNS, IPv6 un pieņemšanu skaidrus

Adrešu tulkošana nelabo vārdu izšķiršanu. Klients var izmantot atrisinātāju, kas piegādāts ar VPN profilu, privātu atrisinātāju konkrētām nosaukumu telpām vai apstiprinātu publisku, un nepieejams atrisinātājs saskaņā ar šo politiku turpinās neizdoties pēc tam, kad maršrutēšana darbosies. Pārbaudiet vārdu un adresi atsevišķi, lai divas kļūmes nekad nesavienotos vienā ziņojumā.

IPv6 dizainā vajag savu rindkopu. Strādājošs IPv4 tulkojums neko nepasaka par to, vai IPv6 klientiem ir maršruts, derīgs publisks avots vai politika, kas tos bloķē, kad tunelis krīt. Atstāt to neizteiktu nozīmē, ka puse klientu klusi apiet vārteju, kamēr otra puse darbojas.

Pieņemšanai izsekojiet vienu atļautu klienta pieprasījumu un tā atbildi pāri abām robežām un pierakstiet, kura adrese katrai robežai tajā brīdī jāredz. Tieši šis ieraksts padara nākamo pūla izmaiņu par piecu minūšu labojumu, nevis strīdu par to, kam pieder trūkstošais atgriešanās maršruts. Glabājiet ierakstu kopā ar klienta profilu, nevis biļetē, jo profilu nākamais inženieris atradīs vispirms.