NAT VPN-palvelimella vai reitittimessä? Molemmat voivat toimia

Yhteyden merkitseminen oletusreitiksi kannettavassa on se vaihe, jonka kaikki muistavat, ja juuri se ei muuta yhdyskäytävässä mitään. Asiakas lähettää nyt internetpyynnöt tunneliin; lähtevätkö ne rakennuksesta, riippuu edelleenlähetyksestä, käännöspisteestä ja paluureitistä, joka saavuttaa asiakkaan yksityisen osoitteen. Kaksi järjestelyä voi tarjota kaikki kolme, ne sijoittavat työn eri paikkoihin, ja molemmat epäonnistuvat samalla hiljaisella tavalla, kun kukaan ei vastaa vastauksen suunnasta. Niiden välillä valitseminen on kysymys siitä, kenen pitäisi nähdä asiakasallas.

Myytti: asiakkaan reitti rakentaa uloskäynnin

Pakotettu tunnelointi on asiakaspuolen käytäntö: se päättää, että liikenne menee VPN-sovittimelle fyysisen sijaan. Microsoftin VPN-reitityksen dokumentaatio kuvaa tuon jakautumisen ja pakottamisen, ja se on väite asiakkaan reititystaulusta, ei palvelimen edelleenlähetyssäännöistä. Asiakkaan näkökulmasta tunneli on paikka, jossa internet asuu; yhdyskäytävän näkökulmasta paketti saapui osoitteesta, josta kukaan ylempänä ei ole koskaan kuullut. Kumpikaan puoli ei ole yksinään väärin määritetty, ja siksi vika näyttää kannettavan ääressä istuvalle rikkinäiseltä palvelimelta.

Tuo epäsuhta on koko ongelma, jonka tämän artikkelin loppuosa ratkaisee. Jonkin on tehtävä asiakkaan yksityisestä osoitteesta palautettava, ja valinta on missä.

Piirrä ensin paluureitti

Kirjoita reitti ylös todellisilla osoitteilla ennen kuin kosket asetukseen, ja merkitse siihen kaksi mahdollista käännöspistettä. Tämä laboratorio käyttää VPN-allasta 10.70.0.0/24 yhdellä asiakkaalla osoitteessa 10.70.0.37, palvelimen LAN-osoitetta 172.16.40.10, reititintä osoitteessa 172.16.40.1 ja julkista uloskäyntiä 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?)

Palvelin, joka jo selaa internetiä, todistaa vain oman reittinsä. Asiakkaan puolesta edelleenlähetetty paketti on eri päätös, jonka tekee saman koneen edelleenlähetyskäytäntö, ja juuri se yleensä puuttuu. Kolmen päätöspisteen merkitseminen kaavioon pitää keskustelun kerrallaan yhdessä niistä.

Vaihtoehto A: käännä VPN-palvelimella

Tässä palvelin kääntää asiakkaan lähteen omaksi LAN-osoitteekseen ennen kuin antaa paketin reitittimelle, ja reititin soveltaa tavallista käännöstään ulospäin. Vastauksessa reitittimen kartoitus palauttaa palvelimen osoitteen ja palvelimen kartoitus palauttaa asiakkaan osoitteen. Kaksi tilallista käännöstä peräkkäin on normaalia ja toimivaa, edellyttäen että molemmat kirjataan; reititin ei koskaan tarvitse reittiä altaaseen, ja se on tämän järjestelyn viehätys.

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

Käytä näitä lukemia nähdäksesi, mitä palvelimella jo on, sen sijaan että olettaisit NAT:n olevan paikallaan. Blogista kopioitu Linuxin masquerade-sääntö ei ole Windowsin kokoonpano, eikä isäntäpalvelimen palomuurin sallimus VPN-kuuntelijalle ole sama käytäntö kuin lupa välittää asiakkaan pyyntö eteenpäin. Vahvista palvelimen edelleenlähetysrooli sen omasta hallintapinnasta ja katso sitten käännöstä erikseen, koska ne kaksi ottaa usein käyttöön käyttöönoton eri osat.

Vaihtoehto B: vie allas reitittimelle

Toisessa järjestelyssä palvelin välittää asiakkaan todellisen lähdeosoitteen ja reititin kääntää sen. Tämä pitää asiakasaltaan näkyvänä reunassa, mikä auttaa, jos reititin on paikka, jossa liikennekäytäntö, lokitus tai tarkastus asuvat. Se tarkoittaa myös, että reititin tarvitsee paluureitin 10.70.0.0/24 kohti, joka osoittaa 172.16.40.10, sekä internetkäytännön, joka todella sisältää tuon etuliitteen; LAN-aliverkolle kirjoitettu sääntö ei hiljaa laajene altaaseen.

Valitse tämä, kun reunalaite on aiottu käytännön omistaja ja voi hyväksyä toisen etuliitteen reititys- ja käännöstauluihinsa. Valitse palvelinpuolen käännös, kun altaan pitäisi pysyä näkymättömänä ylempänä eikä reititintä hallinnoi sama tiimi. Kumpaakaan vaihtoehtoa ei johda mistään asiakkaan valintaruudusta, eikä kumpikaan ole yleisesti ottaen turvallisempi; ne sijoittavat näkyvyyden ja ylläpidon eri paikkoihin.

Tee DNS, IPv6 ja hyväksyntä selkeiksi

Osoitteen käännös ei korjaa nimien selvitystä. Asiakas voi käyttää VPN-profiilin mukana toimitettua selvittäjää, yksityistä selvittäjää tietyille nimiavaruuksille tai hyväksyttyä julkista, ja tavoittamaton selvittäjä tuon käytännön alla epäonnistuu edelleen sen jälkeen, kun reititys toimii. Testaa nimi ja osoite erikseen, jotta kaksi vikaa ei koskaan sulautuisi yhdeksi raportiksi.

IPv6 tarvitsee oman kappaleensa suunnittelussa. Toimiva IPv4-käännös ei kerro mitään siitä, onko IPv6-asiakkailla reitti, kelvollinen julkinen lähde vai käytäntö, joka estää ne, kun tunneli putoaa. Sen sanomatta jättäminen tarkoittaa, että puolet asiakkaista ohittaa yhdyskäytävän hiljaa, kun taas toinen puoli toimii.

Hyväksyntää varten seuraa yhtä sallittua asiakaspyyntöä ja sen vastausta molempien rajojen yli ja kirjoita ylös, minkä osoitteen kunkin rajan pitäisi nähdä sillä hetkellä. Juuri tuo kirjaus tekee seuraavasta allasmuutoksesta viiden minuutin muokkauksen eikä väittelyä siitä, kuka omistaa puuttuvan paluureitin. Pidä kirjaus asiakasprofiilin yhteydessä äläkä tiketissä, sillä profiili on se, minkä seuraava insinööri löytää ensimmäisenä.