SoftEther SecureNAT: DHCP en NAT is twee besluite

SecureNAT is een merkblokkie wat twee dienste aanskakel, en dit is die bron van die meeste verwarring daaroor. ’n Virtuele DHCP-bediener gee die kliënt ’n adres, masker, poort en dikwels ’n oplosser. ’n Virtuele NAT stuur pakkette verby daardie poort met die bediener-gasheer se eie netwerkstapel. Hulle staan langs mekaar in die konfigurasie en faal onafhanklik: ’n kliënt kan ’n perfekte huurkontrak hê en geen werkende pad nie, of ’n werkende pad met instellings wat na die verkeerde oplosser wys. Verifieer hulle as twee besluite, en die diagnose word kort.

Twee dienste agter een merkblokkie

Die virtuele DHCP-kant antwoord ’n konfigurasievraag: watter instellings ontvang hierdie kliënt binne hierdie virtuele hub. Die virtuele NAT-kant antwoord ’n aanstuurvraag: wanneer ’n kliënt ’n pakket na ’n adres buite die hub stuur, vertaal en stuur die bediener dit dan aan. Die eerste is plaaslik aan die hub en benodig geen opstroomnetwerk nie. Die tweede hang heeltemal van die gasheer af.

Die virtuele gasheerkoppelvlak hoort by die eerste besluit, nie die tweede nie. Sy adres, dikwels iets soos 192.168.30.1 by verstek, is die poort wat die DHCP-diens aanbied. Dit is nie die bediener se openbare luisteradres nie, en om die twee te verwar lewer firewallreëls en kliëntinstellings op wat op ’n masjien gemik is wat nie op daardie netwerk bestaan nie.

Besluit 1: wie verskaf die adres

As die virtuele DHCP geaktiveer is, behoort kliënte ’n huurkontrak in die poel te ontvang wat jy opgestel het, met die virtuele gasheerkoppelvlak as poort en watter oplosser jy ook al verskaf het. Ondersoek die huurkontrak eerder as die kliënt se statusteks, want “connected” beskryf die tonnel en nie die adrestoewysing nie:

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

Twee faalmodusse is die moeite werd om te ken voordat jy enigiets anders ontfout. ’n Kliënt met ’n oorblywende statiese adres uit ’n vorige ontwerp sal dit hou en die huurkontrak ignoreer, wat lyk asof DHCP weier om te antwoord. En ’n tweede DHCP-bron op ’n oorbruggde segment sal om dieselfde kliënte meeding, wat wisselende adresse en ’n ondersteuningsry oplewer wat die probleem nie kan herproduseer nie.

Oorvleuelende poele hoort ook hier. As die virtuele DHCP-poel die gasheer se LAN-subnet of ’n ander hub se poel oorvleuel, kry die kliënt ’n adres wat dubbelsinnig roeteer, en elke latere toets is onbeslis.

Besluit 2: wie stuur verby die virtuele poort aan

Met die virtuele NAT geaktiveer, word uitwaartse verkeer van die hub deur die bediener vertaal en deur die gasheer se roetetabel gestuur. Dit beteken die aanstuurketting is: kliënt na virtuele poort, virtuele NAT na gasheerstapel, gasheerstapel na sy verstekroete. Elke skakel kan faal sonder om die ander te raak, en die faalhandtekeninge verskil.

Toets die tweede besluit met iets wat die hub moet verlaat, nie met iets plaasliks daaraan nie. Om die virtuele poort te ping bewys die eerste skakel en niks meer nie:

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

As naamoplossing werk maar verbindings na ’n openbare adres faal, is jy in die aanstuurketting eerder as in DHCP. As albei faal, kyk eerste na die oplosser, want ’n oplosser wat as ’n onbereikbare interne adres gestoot word, sal ’n werkende pad heeltemal stukkend laat lyk.

SecureNAT se aanstuur word deur die bedienerproses geïmplementeer, nie deur die kerenaanstuurpad wat jy met ’n brug sou gebruik nie. Dit is gerieflik en stadiger as oorbrugging, en dit beteken ook dat die gasheer se eie firewallreëls en roetebesluite steeds op die vertaalde verkeer van toepassing is. Die virtuele NAT omseil nie die gasheer se beleid nie; dit gebruik dit.

Die gasheer se eie pad is ’n derde ding

Alles hierbo aanvaar dat die bediener-gasheer die bestemming kan bereik. ’n Gasheer sonder ’n werkende opstroomroete, ’n beperkende uitwaartse beleid, of ’n adresfamilie wat die gasheer nie het nie, sal die tweede besluit faal maak, maak nie saak hoe korrek die hub-konfigurasie is nie. Toets die gasheer op sy eie, buite die tonnel, voordat jy sy mislukking aan SoftEther toeskryf.

SecureNAT is ook nie magtiging om elke netwerk te bereik wat aan die bediener gekoppel is nie. Dit vertaal en stuur verkeer aan wat dit bereik; om te besluit wat die gasheer mag bereik, bly die gasheer se firewall- en roetewerk, en ’n ontwerp wat op die tonnel staatmaak om toegang te verleen, is een slegte reël weg van te veel toegang verleen.

Adresfamilies verdien hul eie kontrole. ’n Werkende IPv4 DHCP-voorbeeld bewys nie dat elke IPv6-vermoë in jou bou teenwoordig is nie, so lees die handleiding vir die weergawe wat jy werklik hardloop voordat jy dubbelstapel-gedrag belowe. Die SecureNAT-afdeling van die handleiding dek die virtuele NAT- en DHCP-funksies vir die huidige vrystelling.

Verifieer elke besluit met sy eie toets

Aanvaar die eerste besluit met ’n huurkontrakkontrole: adres in die poel, poort gelyk aan die virtuele gasheerkoppelvlak, oplosser die een wat jy opgestel het. Aanvaar die tweede met ’n uitwaartse versoek vanaf die kliënt plus ’n blik op die NAT-tabel op die bediener, want ’n stygende sessietelling is die enigste direkte bewyse dat vertaling plaasvind eerder as dat dit bloot geaktiveer is.

Teken dan die verdeling in die ontwerpnota aan: watter komponent die adres verskaf, watter komponent aanstuur, en watter gasheerkoppelvlak die verkeer verlaat. Wanneer ’n herbegin gedrag verander, sê daardie nota watter van die drie jy moet ondersoek in plaas daarvan om alles te herbegin en te hoop die simptoom skuif.

Nog een besluit hoort in die rekord, selfs al neem jy dit nie vandag nie: SecureNAT en ’n plaaslike brug is verskillende ontwerpe vir dieselfde hub, en ’n hub wat albei nodig het, is ’n hub wat ’n ander plan nodig het. Kies doelbewus, skryf neer waarom, en die volgende persoon hoef dit nie uit ’n lopende konfigurasie terug te ontwerp nie.