NAT VPN-serveris või ruuteris? Mõlemad võivad töötada

Ühenduse märkimine sülearvutis vaikimisi marsruudiks on samm, mille kõik mäletavad, ja just see ei muuda lüüsil midagi. Klient saadab nüüd internetipäringud tunnelisse; kas need hoonest väljuvad, sõltub edasisaatmisest, tõlkepunktist ja tagasiteest, mis jõuab kliendi privaatse aadressini. Kaks lahendust suudavad pakkuda kõiki kolme, need panevad töö erinevatesse kohtadesse ja mõlemad nurjuvad samamoodi vaikselt, kui keegi ei vastuta vastuse suuna eest. Nende vahel valimine on küsimus sellest, kes peaks kliendihulka nägema.

Müüt: kliendi marsruut loob väljapääsu

Sunnitud tunnelimine on kliendipoolne poliitika: see otsustab, et liiklus läheb VPN-adapterile, mitte füüsilisele. Microsofti VPN-i marsruutimise dokumentatsioon kirjeldab seda eraldamist ja sunnitud käitumist ning see on väide kliendi marsruuditabeli, mitte serveri edasisaatmisreeglite kohta. Kliendi vaatenurgast on tunnel koht, kus internet elab; lüüsi vaatenurgast saabus pakett aadressilt, millest keegi ülalpool pole kunagi kuulnud. Kumbki pool ei ole iseenesest valesti seadistatud ja seetõttu näeb tõrge sülearvuti juures olevale inimesele välja nagu katkine server.

See lahknevus on kogu probleem, mille ülejäänud artikkel lahendab. Miski peab muutma kliendi privaatse aadressi tagastatavaks ja valik on see, kus.

Joonistage esmalt vastusetee

Kirjutage tee üles tegelike aadressidega enne, kui puudutate ühtegi seadet, ja märkige sellele kaks võimalikku tõlkepunkti. See labor kasutab VPN-i hulka 10.70.0.0/24 ühe kliendiga aadressil 10.70.0.37, serveri LAN-aadressi 172.16.40.10, ruuterit aadressil 172.16.40.1 ja avalikku väljapääsu 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?)

Server, mis juba internetis sirvib, tõestab ainult omaenda teed. Kliendi nimel edasi saadetud pakett on teistsugune otsus, mille teeb edasisaatmispoliitika samas masinas, ja just seda tavaliselt puudub. Kolme otsustuspunkti märkimine skeemile hoiab vestluse korraga ühe juures.

Valik A: tõlkimine VPN-serveris

Siin tõlgib server kliendi allika oma LAN-aadressiks enne paketi ruuterile andmist ja ruuter rakendab väljaminekul oma tavalist tõlget. Vastusel taastab ruuteri vastendus serveri aadressi ja serveri vastendus taastab kliendi aadressi. Kaks olekut omavat tõlget järjestikku on tavaline ja teostatav, eeldusel et mõlemad on kirja pandud; ruuter ei vaja kunagi marsruuti hulgani ja see on selle lahenduse võlu.

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

Kasutage neid lugemisi, et näha, mis serveril juba on, selle asemel et eeldada NAT-i olemasolu. Blogist kopeeritud Linuxi masquerade-reegel ei ole Windowsi seadistus ja hosti tulemüüri luba VPN-kuulajale ei ole sama poliitika kui luba kliendi päring edasi saata. Kinnitage serveri edasisaatmisroll selle enda haldusliidesest, seejärel vaadake tõlget eraldi, sest neid kahte lubavad sageli juurutuse erinevad osad.

Valik B: viige hulk ruuterisse

Teises lahenduses saadab server edasi kliendi tegeliku lähteaadressi ja ruuter tõlgib selle. See hoiab kliendihulga servas nähtavana, mis aitab siis, kui ruuter on koht, kus elab liikluspoliitika, logimine või kontroll. See tähendab ka, et ruuter vajab tagasimarsruuti 10.70.0.0/24 jaoks, mis osutab aadressile 172.16.40.10, pluss internetipoliitikat, mis seda prefiksit tegelikult sisaldab; LAN-i alavõrgu jaoks kirjutatud reegel ei laiene vaikselt hulgale.

Valige see, kui servaseade on kavandatud poliitikaomanik ja suudab oma marsruutimis- ja tõlketabelites vastu võtta veel ühe prefiksi. Valige serveripoolne tõlkimine, kui hulk peaks ülalpool nähtamatuks jääma ja ruuterit ei halda sama meeskond. Kumbagi valikut ei vihja ükski kliendi märkeruut ja kumbki ei ole üldiselt turvalisem; need paigutavad nähtavuse ja hoolduse erinevatesse kohtadesse.

Tehke DNS, IPv6 ja vastuvõtt selgesõnaliseks

Aadresside tõlkimine ei paranda nimede lahendamist. Klient võib kasutada VPN-profiiliga kaasas olevat resolverit, konkreetsete nimeruumide jaoks privaatset resolverit või heakskiidetud avalikku, ja selle poliitika all kättesaamatu resolver jätkab nurjumist ka pärast seda, kui marsruutimine töötab. Testige nime ja aadressi eraldi, et kaks tõrget ei sulanduks kunagi üheks aruandeks.

IPv6 vajab kavandis omaette lõiku. Töötav IPv4 tõlge ei ütle midagi selle kohta, kas IPv6 klientidel on marsruut, kehtiv avalik allikas või poliitika, mis blokeerib need, kui tunnel langeb. Selle ütlemata jätmine tähendab, et pooled kliendid mööduvad lüüsist vaikselt, samal ajal kui teine pool töötab.

Vastuvõtu jaoks jälgige ühte lubatud kliendipäringut ja selle vastust mõlemal piiril ning kirjutage üles, millist aadressi peaks kumbki piir sel hetkel nägema. Just see kirje muudab järgmise hulga muudatuse viie minuti muudatuseks, mitte vaidluseks selle üle, kes omab puuduvat tagasimarsruuti. Hoidke kirjet kliendiprofiili juures, mitte piletil, sest profiil on see, mille järgmine insener kõigepealt leiab.