SoftEther SecureNAT: DHCP ja NAT ovat kaksi päätöstä

SecureNAT on yksi valintaruutu, joka kytkee päälle kaksi palvelua, ja juuri siitä tulee suurin osa siihen liittyvästä sekaannuksesta. Virtuaalinen DHCP-palvelin antaa asiakkaalle osoitteen, maskin, yhdyskäytävän ja usein resolverin. Virtuaalinen NAT välittää paketteja tuon yhdyskäytävän ohi käyttäen palvelinkoneen omaa verkkopinoa. Ne seisovat asetuksissa vierekkäin ja pettävät toisistaan riippumatta: asiakkaalla voi olla täydellinen vuokra ja ei toimivaa reittiä, tai toimiva reitti asetuksilla, jotka osoittavat väärään resolveriin. Tarkista ne kahtena päätöksenä, niin diagnoosista tulee lyhyt.

Kaksi palvelua yhden valintaruudun takana

Virtuaalisen DHCP:n puoli vastaa asetuskysymykseen: mitkä asetukset tämä asiakas saa tämän virtuaalisen hubin sisällä. Virtuaalisen NATin puoli vastaa välityskysymykseen: kun asiakas lähettää paketin hubin ulkopuoliseen osoitteeseen, kääntääkö ja välittääkö palvelin sen. Ensimmäinen on hubille paikallinen eikä tarvitse ylävirran verkkoa. Toinen riippuu täysin isännästä.

Virtuaalinen isäntäliittymä kuuluu ensimmäiseen päätökseen, ei toiseen. Sen osoite, usein oletuksena jotain 192.168.30.1:n kaltaista, on yhdyskäytävä, jota DHCP-palvelu tarjoaa. Se ei ole palvelimen julkinen kuunteluosoite, ja näiden kahden sekoittaminen tuottaa palomuurisääntöjä ja asiakasasetuksia, jotka osoittavat koneeseen, jota siinä verkossa ei ole.

Päätös 1: kuka toimittaa osoitteen

Jos virtuaalinen DHCP on käytössä, asiakkaiden pitäisi saada vuokra määrittämästäsi altaasta, yhdyskäytävänä virtuaalinen isäntäliittymä ja resolverina se, jonka annoit. Tarkastele vuokraa äläkä asiakkaan tilatekstiä, sillä «yhdistetty» kuvaa tunnelia eikä osoitteen jakoa:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Kaksi vikatilaa kannattaa tuntea ennen kuin alat selvittää mitään muuta. Asiakas, jolla on edellisestä suunnitelmasta jäänyt staattinen osoite, pitää sen ja jättää vuokran huomiotta, mikä näyttää siltä kuin DHCP kieltäytyisi vastaamasta. Ja toinen DHCP-lähde sillatussa segmentissä kilpailee samoista asiakkaista, mikä tuottaa ajoittaisia osoitteita ja tukijonon, joka ei pysty toistamaan ongelmaa.

Päällekkäiset altaat kuuluvat myös tänne. Jos virtuaalisen DHCP:n allas menee isännän lähiverkon aliverkon tai toisen hubin altaan päälle, asiakas saa osoitteen, joka reitittyy monitulkintaisesti, ja jokainen myöhempi testi on epäselvä.

Päätös 2: kuka välittää virtuaalisen yhdyskäytävän ohi

Kun virtuaalinen NAT on käytössä, palvelin kääntää hubista lähtevän liikenteen ja lähettää sen isännän reititystaulukon kautta. Se tarkoittaa, että välitysketju on: asiakas virtuaaliseen yhdyskäytävään, virtuaalinen NAT isännän pinoon, isännän pino oletusreittiinsä. Jokainen lenkki voi pettää koskematta muihin, ja vikojen tunnusmerkit eroavat.

Testaa toinen päätös jollakin, jonka on poistuttava hubista, ei jollakin siihen paikallisella. Virtuaalisen yhdyskäytävän pingaaminen todistaa ensimmäisen lenkin eikä mitään muuta:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Jos nimien selvitys toimii mutta yhteydet julkiseen osoitteeseen epäonnistuvat, olet välitysketjussa etkä DHCP:ssä. Jos molemmat epäonnistuvat, tarkista ensin resolveri, sillä saavuttamattomana sisäisenä osoitteena jaettu resolveri saa toimivan reitin näyttämään täysin rikkinäiseltä.

SecureNATin välityksen toteuttaa palvelinprosessi, ei se ytimen välityspolku, jota käyttäisit sillan kanssa. Se on kätevää ja hitaampaa kuin sillaksi kytkeminen, ja se tarkoittaa myös, että isännän omat palomuurisäännöt ja reitityspäätökset pätevät edelleen käännetylle liikenteelle. Virtuaalinen NAT ei ohita isännän käytäntöä; se käyttää sitä.

Isännän oma reitti on kolmas asia

Kaikki edellä olettaa, että palvelinisäntä tavoittaa kohteen. Isäntä, jolla ei ole toimivaa ylävirran reittiä, jolla on rajoittava lähtevä käytäntö tai jolla ei ole sitä osoiteperhettä, epäonnistuu toisessa päätöksessä, oli hubin kokoonpano miten oikea tahansa. Tarkista isäntä erikseen, tunnelin ulkopuolella, ennen kuin kohdistat sen vian SoftEtheriin.

SecureNAT ei myöskään ole valtuutus tavoittaa jokaista palvelimeen liitettyä verkkoa. Se kääntää ja välittää liikennettä, joka saavuttaa sen; päättäminen siitä, mitä isäntä saa tavoittaa, on edelleen isännän palomuurin ja reitityksen työtä, ja suunnitelma, joka luottaa tunneliin pääsyn antamisessa, on yhden huonon säännön päässä liian paljon antamisesta.

Osoiteperheet ansaitsevat oman tarkistuksensa. Toimiva IPv4 DHCP -esimerkki ei osoita, että jokainen IPv6-ominaisuus on koosteessasi, joten lue sen version käsikirjaa, jota todella ajat, ennen kuin lupaat kaksoispinon käyttäytymistä. Käsikirjan SecureNAT-osio kattaa virtuaaliset NAT- ja DHCP-toiminnot nykyiselle julkaisulle.

Tarkista jokainen päätös omalla testillään

Hyväksy ensimmäinen päätös vuokran tarkistuksella: osoite altaassa, yhdyskäytävä sama kuin virtuaalinen isäntäliittymä, resolveri se, jonka määritit. Hyväksy toinen asiakkaan lähtevällä pyynnöllä ja vilkaisulla palvelimen NAT-taulukkoon, sillä kasvava istuntojen määrä on ainoa suora todiste siitä, että käännös tapahtuu eikä vain että se on kytketty päälle.

Kirjaa sitten jako suunnittelumuistioon: mikä komponentti toimittaa osoitteen, mikä komponentti välittää ja mitä isäntäliittymää liikenne poistuu. Kun uudelleenkäynnistys muuttaa käyttäytymistä, se muistio kertoo, mitä kolmesta tarkastella, sen sijaan että käynnistäisit kaiken uudelleen ja toivoisit oireen siirtyvän.

Vielä yksi päätös kuuluu kirjaan, vaikka et tekisi sitä tänään: SecureNAT ja paikallinen silta ovat eri suunnitelmia samalle hubille, ja hubi, joka tarvitsee molemmat, on hubi, joka tarvitsee toisen suunnitelman. Valitse tietoisesti, kirjoita miksi, niin seuraavan henkilön ei tarvitse päätellä sitä taaksepäin käynnissä olevasta kokoonpanosta.