NAT na VPN serveru ili na usmjerivaču? Oboje može raditi

Označavanje veze kao zadane rute na prijenosnom računalu je korak koji svi pamte, i upravo on ne mijenja ništa na pristupniku. 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 ne uspiju na isti tihi način kada nitko ne posjeduje smjer odgovora. Odabir između njih je pitanje o tome koga treba vidjeti klijentski skup.

Mit: klijentska ruta gradi izlaz

Prisilno tuneliranje politika je na strani klijenta: odlučuje da promet ide na VPN adapter umjesto na fizički. Microsoftova dokumentacija o VPN usmjeravanju 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 pristupnika paket je stigao s adrese za koju nitko uzvodno nikada nije čuo. Ni jedna strana nije pogrešno konfigurirana sama po sebi, i zato kvar osobi pokraj prijenosnog računala izgleda kao pokvaren server.

Taj nesklad cijeli je 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 laboratorij koristi VPN skup 10.70.0.0/24 s jednim klijentom na 10.70.0.37, LAN adresu servera 172.16.40.10, usmjerivač 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ć pregledava internet dokazuje samo svoju putanju. Paket proslijeđen u ime klijenta druga je 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 usmjerivaču, a usmjerivač primjenjuje svoje uobičajeno prevođenje na izlazu. Na odgovoru, usmjerivačevo mapiranje vraća adresu servera, a serverovo mapiranje vraća adresu klijenta. Dva prevođenja sa stanjem u nizu normalna su i izvediva, pod uvjetom da su oba zabilježena; usmjerivač nikada ne treba rutu do skupa, i to je privlačnost ovog rasporeda.

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

Koristite ova čitanja da vidite što 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šatelja 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 skup na usmjerivač

U drugom rasporedu server prosljeđuje klijentovu stvarnu izvornu adresu, a usmjerivač je prevodi. To drži klijentski skup vidljivim na rubu, što pomaže ako je usmjerivač mjesto gdje žive prometna politika, logiranje ili inspekcija. To također znači da usmjerivaču 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 skup.

Odaberite ovo kada je rubni uređaj namjeravani vlasnik politike i može prihvatiti drugi prefiks u svojim tablicama usmjeravanja i prevođenja. Odaberite prevođenje na strani servera kada skup treba ostati nevidljiv uzvodno i usmjerivačem 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 ne uspijevati nakon što usmjeravanje proradi. Testirajte ime i adresu odvojeno kako se dva kvara nikada ne bi spojila u jedan izvještaj.

IPv6 treba vlastiti odlomak 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 pristupnik dok druga polovica 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 je zapis ono što sljedeću promjenu skupa čini petominutnom izmjenom umjesto raspravom o tome ko posjeduje nedostajuću povratnu rutu. Držite zapis uz klijentski profil, a ne u ticketu, jer profil je ono što će sljedeći inženjer prvo naći.