SoftEther SecureNAT: DHCP og NAT er to avgjerder

SecureNAT er ein einaste avkryssingsboks som slår på to tenester, og det er kjelda til det meste av forvirringa rundt det. Ein virtuell DHCP-tenar gjev klienten ei adresse, ei maske, ein gateway og ofte ein resolvar. Ein virtuell NAT sender pakkar forbi den gatewayen ved hjelp av nettverksstakken til serververten sjølv. Dei står ved sida av kvarandre i konfigurasjonen og sviktar uavhengig: ein klient kan ha ei perfekt leige og ingen veg som fungerer, eller ein veg som fungerer med innstillingar som peikar på feil resolvar. Kontroller dei som to avgjerder, og diagnosen vert kort.

To tenester bak ein avkryssingsboks

DHCP-sida svarar på eit konfigurasjonsspørsmål: kva innstillingar får denne klienten inne i denne virtuelle huben. NAT-sida svarar på eit videresendingsspørsmål: når ein klient sender ein pakke til ei adresse utanfor huben, set tenaren han om og sender han vidare. Den første er lokal for huben og treng ikkje noko nettverk oppstraums. Den andre heng heilt på verten.

Det virtuelle vertsgrensesnittet høyrer til den første avgjerda, ikkje den andre. Adressa, ofte noko som 192.168.30.1 som standard, er gatewayen som DHCP-tenesta tilbyr. Ho er ikkje den offentlege lyttadressa til tenaren, og å blanda dei to gjev brannmurreglar og klientinnstillingar retta mot ein maskin som ikkje finst på det nettverket.

Avgjerd 1: kven som leverer adressa

Viss den virtuelle DHCP-en er slått på, bør klientar få ei leige i utvalet du sette opp, med det virtuelle vertsgrensesnittet som gateway og resolvaren du oppgav. Sjå på leiga og ikkje statusteksten til klienten, fordi «tilkopla» skildrar tunnelen og ikkje adressetildelinga:

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

To feilmodus er verd å kjenna før du feilsøkjer noko anna. Ein klient med ei attverande statisk adresse frå eit tidlegare design held på ho og overser leiga, noko som ser ut som om DHCP nektar å svara. Og ei anna DHCP-kjelde på eit brua segment vil tevla om dei same klientane, noko som gjev sporadiske adresser og ein støttekø som ikkje kan gjenskapa problemet.

Overlappande utval høyrer også heime her. Viss det virtuelle DHCP-utvalet overlappar LAN-subnettet til verten eller utvalet til ein annan hub, får klienten ei adresse som blir ruta tvitydig, og kvar seinare test er intetsigande.

Avgjerd 2: kven som sender vidare forbi den virtuelle gatewayen

Med den virtuelle NAT-en slått på blir utgåande trafikk frå huben sett om av tenaren og send gjennom rutetabellen til verten. Det tyder at videresendingskjeda er: klient til virtuell gateway, virtuell NAT til stakken til verten, stakken til verten til standardruta si. Kvar lenkje kan svikta utan å røra dei andre, og feilsignatura er ulike.

Test den andre avgjerda med noko som må forlata huben, ikkje med noko som er lokalt for han. Å pinga den virtuelle gatewayen provar den første lenkja og ikkje noko meir:

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

Viss namneoppslag fungerer, men tilkoplingar til ei offentleg adresse feilar, er du i videresendingskjeda og ikkje i DHCP. Viss begge feilar, sjekk resolvaren først, fordi ein resolvar som blir dytta ut som ei utilgjengeleg intern adresse vil få ein veg som fungerer til å sjå heilt øydelagd ut.

Videresendinga til SecureNAT blir gjennomført av tenarprosessen, ikkje av kjernevideresendingsvegen du ville brukt med ei bru. Det er praktisk og seinare enn bruing, og det tyder også at verten sine eigne brannmurreglar og rutingsavgjerder framleis gjeld for den omsette trafikken. Den virtuelle NAT-en omgår ikkje politikken til verten; han brukar han.

Vegen til verten sjølv er ein tredje ting

Alt ovanfor føreset at serververten kan nå destinasjonen. Ein vert utan ein fungerande rute oppstraums, med ein restriktiv utgåande politikk eller med ei adressefamilie han ikkje har, vil feila den andre avgjerda, same kor riktig hubkonfigurasjonen er. Kontroller verten for seg sjølv, utanfor tunnelen, før du legg feilen hans på SoftEther.

SecureNAT er heller ikkje ei autorisering til å nå kvart nettverk som er knytt til tenaren. Det set om og sender vidare trafikk som når det; å avgjera kva verten får nå er framleis brannmur- og ruterarbeid for verten, og eit design som reknar med tunnelen for å gje tilgang er éin dårleg regel frå å gje for mykje.

Adressefamiliar fortener sin eigen kontroll. Eit fungerande IPv4 DHCP-døme fastslår ikkje at kvar IPv6-eigenskap er til stades i bygget ditt, så les handboka for versjonen du faktisk køyrer før du lovar dobbeltstakk-åtferd. SecureNAT-avsnittet i handboka dekkjer dei virtuelle NAT- og DHCP-funksjonane for gjeldande utgåve.

Kontroller kvar avgjerd med sin eigen test

Godta den første avgjerda med ein leigekontroll: adresse i utvalet, gateway lik det virtuelle vertsgrensesnittet, resolvar den du sette opp. Godta den andre med ein utgåande førespurnad frå klienten pluss eit blikk på NAT-tabellen på tenaren, fordi eit aukande tal på sesjonar er det einaste direkte provet på at omsetjinga skjer og ikkje berre at ho er slått på.

Skriv så oppdelinga i designnotatet: kva komponent som leverer adressa, kva komponent som sender vidare, og kva vertsgrensesnitt trafikken går ut gjennom. Når ein omstart endrar åtferd, fortel notatet deg kva av dei tre du skal undersøkja i staden for å starta alt på nytt og håpa at symptomet flyttar seg.

Éi avgjerd til høyrer heime i protokollen, sjølv om du ikkje tek ho i dag: SecureNAT og ei lokal bru er ulike design for den same huben, og ein hub som treng begge er ein hub som treng ein annan plan. Vel medvite, skriv ned kvifor, og neste person slepp å gjenskapa det baklengs frå ein køyrande konfigurasjon.