NAT na VPN serveru ili na ruteru? Oboje može raditi

Označavanje veze kao zadane rute na laptopu je korak koji svi pamte, i upravo on ne mijenja ništa na gatewayu. Klijent sada šalje internetske zahtjeve u tunel; hoće li napustiti zgradu zavisi od prosljeđivanja, točke prevođenja i povratne putanje koja stiže do klijentove privatne adrese. Dva rasporeda mogu pružiti sva tri, oni stavljaju posao na različita mjesta, i oba neuspijevaju na isti tihi način kada niko ne posjeduje smjer odgovora. Odabir između njih je pitanje o tome ko treba vidjeti klijentski pul.

Mit: klijentska ruta gradi izlaz

Prisilno tuneliranje je politika na strani klijenta: odlučuje da promet ide na VPN adapter umjesto na fizički. Microsoftova dokumentacija o VPN rutiranju opisuje to razdvajanje i prisilno ponašanje, i to je tvrdnja o klijentovoj tablici ruta, a ne o serverovim pravilima prosljeđivanja. Iz perspektive klijenta tunel je mjesto gdje živi internet; iz perspektive gatewaya paket je stigao sa adrese za koju niko uzvodno nikada nije čuo. Ni jedna strana nije pogrešno konfigurisana sama po sebi, i zato kvar osobi pored laptopa izgleda kao pokvaren server.

Taj nesklad je cijeli problem koji ostatak ovog članka rješava. Nešto mora učiniti klijentovu privatnu adresu povratnom, a izbor je gdje.

Prvo nacrtajte povratnu putanju

Zapišite putanju sa stvarnim adresama prije nego dotaknete bilo koju postavku, i označite na njoj dvije moguće točke prevođenja. Ovaj lab koristi VPN pul 10.70.0.0/24 s jednim klijentom na 10.70.0.37, LAN adresu servera 172.16.40.10, ruter na 172.16.40.1 i javni izlaz 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 koji već pregleda internet dokazuje samo svoju putanju. Paket proslijeđen u ime klijenta je druga odluka, koju donosi politika prosljeđivanja na istom stroju, i obično nedostaje upravo ona. Označavanje tri točke odluke na dijagramu drži razgovor o jednoj od njih u jednom trenutku.

Opcija A: prevođenje na VPN serveru

Ovdje server prevodi klijentov izvor na vlastitu LAN adresu prije nego preda paket ruteru, a ruter primjenjuje svoje uobičajeno prevođenje na izlazu. Na odgovoru, ruterovo mapiranje vraća adresu servera, a serverovo mapiranje vraća adresu klijenta. Dva prevođenja sa stanjem u nizu su normalna i izvediva, pod uslovom da su oba zabilježena; ruter nikada ne treba rutu do pula, i to je privlačnost ovog rasporeda.

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

Koristite ova čitanja da vidite šta server već ima umjesto da pretpostavljate da je NAT na mjestu. Linux masquerade pravilo kopirano s bloga nije Windows konfiguracija, a dozvola u host firewallu za VPN slušalac nije ista politika kao dozvola da se klijentov zahtjev proslijedi dalje. Potvrdite serverovu ulogu prosljeđivanja s njegove vlastite upravljačke površine, pa onda pogledajte prevođenje odvojeno, jer njih dvoje često uključuju različiti dijelovi implementacije.

Opcija B: prenesite pul na ruter

U drugom rasporedu server prosljeđuje klijentovu stvarnu izvornu adresu, a ruter je prevodi. To drži klijentski pul vidljivim na rubu, što pomaže ako je ruter mjesto gdje žive prometna politika, logiranje ili inspekcija. To također znači da ruteru treba povratna ruta za 10.70.0.0/24 koja pokazuje na 172.16.40.10, plus internetska politika koja zaista uključuje taj prefiks; pravilo napisano za LAN podmrežu ne širi se tiho na pul.

Odaberite ovo kada je rubni uređaj namjeravani vlasnik politike i može prihvatiti drugi prefiks u svojim tablicama rutiranja i prevođenja. Odaberite prevođenje na strani servera kada pul treba ostati nevidljiv uzvodno i ruterom ne upravlja isti tim. Ni jedna opcija nije implicirana nijednim poljem za potvrdu na klijentu, i ni jedna nije općenito sigurnija; one stavljaju vidljivost i održavanje na različita mjesta.

Učinite DNS, IPv6 i prihvat eksplicitnim

Prevođenje adresa ne popravlja razrješavanje imena. Klijent može koristiti resolver isporučen s VPN profilom, privatni resolver za određene prostore imena ili odobreni javni, a nedostupni resolver pod tom politikom nastavit će neuspijevati nakon što rutiranje proradi. Testirajte ime i adresu odvojeno kako se dva kvara nikada ne bi spojila u jedan izvještaj.

IPv6 treba vlastiti pasus u dizajnu. Ispravno IPv4 prevođenje ne govori ništa o tome imaju li IPv6 klijenti rutu, valjani javni izvor ili politiku koja ih blokira kada tunel padne. Ostaviti to neizrečenim znači da pola klijenata tiho zaobilazi gateway dok druga polovina radi.

Za prihvat pratite jedan dopušteni klijentski zahtjev i njegov odgovor preko obje granice i zapišite adresu koju svaka granica treba vidjeti u tom trenutku. Taj zapis je ono što sljedeću promjenu pula čini petominutnom izmjenom umjesto raspravom o tome ko posjeduje nedostajuću povratnu rutu. Držite zapis uz klijentski profil, a ne u tiketu, jer profil je ono što će sljedeći inženjer prvo naći.