NAT VPN serveryje ar maršrutizatoriuje? Abu variantai gali veikti

Ryšio pažymėjimas numatytuoju maršrutu nešiojamajame kompiuteryje yra žingsnis, kurį visi atsimena, ir būtent jis nieko nekeičia šliuze. Klientas dabar siunčia interneto užklausas į tunelį; ar jos paliks pastatą, priklauso nuo perdavimo, vertimo taško ir grįžtamojo kelio, kuris pasiekia kliento privatų adresą. Dvi konfigūracijos gali suteikti visus tris, jos paskirsto darbą skirtingose vietose, ir abi nepavyksta tuo pačiu tyliu būdu, kai niekas neatsako už atsakymo kryptį. Pasirinkimas tarp jų yra klausimas, kas turėtų matyti klientų telkinį.

Mitas: kliento maršrutas sukuria išėjimą

Priverstinis tuneliavimas yra kliento pusės politika: ji nusprendžia, kad srautas eis į VPN adapterį, o ne į fizinį. Microsoft VPN maršrutizavimo dokumentacija aprašo tą skaidymą ir priverstinį elgesį, ir tai yra teiginys apie kliento maršrutų lentelę, o ne apie serverio perdavimo taisykles. Kliento požiūriu tunelis yra vieta, kurioje gyvena internetas; šliuzo požiūriu paketas atėjo iš adreso, apie kurį niekas aukščiau niekada negirdėjo. Nė viena pusė atskirai nėra neteisingai sukonfigūruota, ir todėl gedimas asmeniui prie nešiojamojo atrodo kaip sugedęs serveris.

Tas neatitikimas yra visa problema, kurią sprendžia likusi straipsnio dalis. Kažkas turi padaryti kliento privatų adresą grąžinamu, ir pasirinkimas yra kur.

Pirmiausia nubrėžkite atsakymo kelią

Užrašykite kelią su tikrais adresais prieš liesdami bet kokį nustatymą, ir pažymėkite jame du galimus vertimo taškus. Ši laboratorija naudoja 10.70.0.0/24 VPN telkinį su vienu klientu 10.70.0.37 adresu, serverio LAN adresą 172.16.40.10, maršrutizatorių 172.16.40.1 adresu ir viešą išėjimą 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, kuris jau naršo internete, įrodo tik savo kelią. Paketas, persiųstas kliento vardu, yra kitas sprendimas, kurį priima tos pačios mašinos perdavimo politika, ir būtent jo paprastai trūksta. Trijų sprendimo taškų pažymėjimas diagramoje išlaiko pokalbį apie vieną iš jų vienu metu.

A variantas: vertimas VPN serveryje

Čia serveris išverčia kliento šaltinį į savo LAN adresą prieš perduodamas paketą maršrutizatoriui, o maršrutizatorius išėjimo kelyje taiko savo įprastą vertimą. Atsakyme maršrutizatoriaus susiejimas atkuria serverio adresą, o serverio susiejimas atkuria kliento adresą. Du būsenos vertimai iš eilės yra normalūs ir įgyvendinami, jei abu užregistruoti; maršrutizatoriui niekada nereikia maršruto į telkinį, ir tai yra šios konfigūracijos patrauklumas.

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

Naudokite šiuos nuskaitymus norėdami pamatyti, ką serveris jau turi, o ne manydami, kad NAT yra vietoje. Iš tinklaraščio nukopijuota Linux masquerade taisyklė nėra Windows konfigūracija, o leidimas pagrindinio kompiuterio ugniasienėje VPN klausytojui nėra ta pati politika kaip leidimas persiųsti kliento užklausą toliau. Patvirtinkite serverio perdavimo vaidmenį iš jo paties valdymo sąsajos, tada pažiūrėkite vertimą atskirai, nes abu dažnai įjungiami skirtingų diegimo dalių.

B variantas: telkinio perkėlimas į maršrutizatorių

Antroje konfigūracijoje serveris persiunčia tikrąjį kliento šaltinio adresą, o maršrutizatorius jį išverčia. Tai palieka klientų telkinį matomą krašte, kas padeda, jei maršrutizatorius yra vieta, kur gyvena srauto politika, registravimas ar tikrinimas. Tai taip pat reiškia, kad maršrutizatoriui reikia grįžtamojo maršruto 10.70.0.0/24, nukreipto į 172.16.40.10, ir interneto politikos, kuri iš tikrųjų apima tą priešdėlį; taisyklė, parašyta LAN potinkiui, tyliai neplinta į telkinį.

Rinkitės tai, kai krašto įrenginys yra numatytas politikos savininkas ir gali priimti dar vieną priešdėlį savo maršrutizavimo ir vertimo lentelėse. Rinkitės serverio pusės vertimą, kai telkinys turi likti nematomas aukščiau ir maršrutizatoriaus neadministruoja ta pati komanda. Nė vieno varianto nenumato joks žymimasis langelis kliente, ir nė vienas nėra apskritai saugesnis; jie paskirsto matomumą ir priežiūrą skirtingose vietose.

Padarykite DNS, IPv6 ir priėmimą aiškius

Adresų vertimas neištaiso vardų sprendimo. Klientas gali naudoti sprendėją, pateiktą su VPN profiliu, privatų sprendėją tam tikroms vardų erdvėms arba patvirtintą viešą, ir nepasiekiamas sprendėjas pagal tą politiką ir toliau žlugs po to, kai maršrutizavimas pradės veikti. Tikrinkite vardą ir adresą atskirai, kad du gedimai niekada nesusilietų į vieną ataskaitą.

IPv6 dizaine reikia atskiro skyriaus. Veikiantis IPv4 vertimas nieko nesako apie tai, ar IPv6 klientai turi maršrutą, galiojantį viešą šaltinį ar politiką, kuri juos blokuoja, kai tunelis nukrinta. Palikus tai nepasakyta, pusė klientų tyliai apeina šliuzą, o kita pusė veikia.

Priėmimo tikslais sekite vieną leistiną kliento užklausą ir jos atsakymą per abi ribas ir užrašykite, kokį adresą kiekviena riba turėtų matyti tuo momentu. Būtent šis įrašas paverčia kitą telkinio pakeitimą penkių minučių redagavimu, o ne ginču, kam priklauso trūkstamas grįžtamasis maršrutas. Laikykite įrašą su kliento profiliu, o ne biliete, nes profilį kitas inžinierius ras pirmiausia.