SoftEther SecureNAT: DHCP og NAT er to beslutninger

SecureNAT er én enkelt avmerkingsboks som slår på to tjenester, og det er kilden til det meste av forvirringen rundt det. En virtuell DHCP-server gir klienten en adresse, en maske, en gateway og ofte en resolver. En virtuell NAT videresender pakker forbi den gatewayen ved hjelp av serververtens egen nettverksstabel. De står ved siden av hverandre i konfigurasjonen og svikter uavhengig: en klient kan ha en perfekt leie og ingen fungerende vei, eller en fungerende vei med innstillinger som peker på feil resolver. Kontroller dem som to avgjørelser, og diagnosen blir kort.

To tjenester bak én avmerkingsboks

DHCP-siden svarer på et konfigurasjonsspørsmål: hvilke innstillinger får denne klienten inne i denne virtuelle huben. NAT-siden svarer på et videresendingsspørsmål: når en klient sender en pakke til en adresse utenfor huben, oversetter og videresender serveren den. Den første er lokal for huben og trenger ingen nettverk oppstrøms. Den andre avhenger helt av verten.

Det virtuelle vertsgrensesnittet hører til den første avgjørelsen, ikke den andre. Adressen, ofte noe som 192.168.30.1 som standard, er gatewayen som DHCP-tjenesten tilbyr. Den er ikke serverens offentlige lyttadresse, og å forveksle de to gir brannmurregler og klientinnstillinger rettet mot en maskin som ikke finnes på det nettverket.

Avgjørelse 1: hvem som leverer adressen

Hvis den virtuelle DHCP-en er slått på, bør klienter få en leie i utvalget du konfigurerte, med det virtuelle vertsgrensesnittet som gateway og resolveren du oppga. Se på leien og ikke klientens statustekst, fordi «tilkoblet» beskriver tunnelen og ikke adressetildelingen:

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

To feilmoduser er verdt å kjenne før du feilsøker noe annet. En klient med en gjenværende statisk adresse fra et tidligere design beholder den og ignorerer leien, noe som ser ut som om DHCP nekter å svare. Og en annen DHCP-kilde på et broet segment vil konkurrere om de samme klientene, noe som gir sporadiske adresser og en støttekø som ikke kan gjenskape problemet.

Overlappende utvalg hører også hjemme her. Hvis det virtuelle DHCP-utvalget overlapper vertens LAN-subnett eller utvalget til en annen hub, får klienten en adresse som rutes tvetydig, og hver senere test er intetsigende.

Avgjørelse 2: hvem som videresender forbi den virtuelle gatewayen

Med den virtuelle NAT-en slått på oversettes utgående trafikk fra huben av serveren og sendes gjennom vertens rutingtabell. Det betyr at videresendingskjeden er: klient til virtuell gateway, virtuell NAT til vertens stabel, vertens stabel til dens standardrute. Hver lenke kan svikte uten å berøre de andre, og feilsignaturene er forskjellige.

Test den andre avgjørelsen med noe som må forlate huben, ikke med noe som er lokalt for den. Å pinge den virtuelle gatewayen beviser den første lenken og ikke noe mer:

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

Hvis navneoppslag fungerer, men tilkoblinger til en offentlig adresse feiler, er du i videresendingskjeden og ikke i DHCP. Hvis begge feiler, sjekk resolveren først, fordi en resolver som dyttes ut som en utilgjengelig intern adresse vil få en fungerende vei til å se fullstendig ødelagt ut.

Videresendingen til SecureNAT implementeres av serverprosessen, ikke av kjernevideresendingsveien du ville brukt med en bro. Det er praktisk og tregere enn å bro, og det betyr også at vertens egne brannmurregler og rutingsbeslutninger fortsatt gjelder for den oversatte trafikken. Den virtuelle NAT-en omgår ikke vertens policy; den bruker den.

Vertens egen vei er en tredje ting

Alt ovenfor forutsetter at serververten kan nå destinasjonen. En vert uten en fungerende rute oppstrøms, med en restriktiv utgående policy eller med en adressefamilie den ikke har, vil feile den andre avgjørelsen, uansett hvor riktig hubkonfigurasjonen er. Kontroller verten for seg selv, utenfor tunnelen, før du tilskriver feilen til SoftEther.

SecureNAT er heller ikke en autorisasjon til å nå hvert nettverk som er koblet til serveren. Det oversetter og videresender trafikk som når det; å avgjøre hva verten får nå er fortsatt vertens brannmur- og rutingarbeid, og et design som regner med tunnelen for å gi tilgang er én dårlig regel fra å gi for mye.

Adressefamilier fortjener sin egen kontroll. Et fungerende IPv4 DHCP-eksempel fastslår ikke at enhver IPv6-egenskap er til stede i bygget ditt, så les håndboken for versjonen du faktisk kjører før du lover dobbeltstakk-atferd. SecureNAT-avsnittet i håndboken dekker de virtuelle NAT- og DHCP-funksjonene for gjeldende utgivelse.

Kontroller hver avgjørelse med sin egen test

Godta den første avgjørelsen med en leiekontroll: adresse i utvalget, gateway lik det virtuelle vertsgrensesnittet, resolver den du konfigurerte. Godta den andre med en utgående forespørsel fra klienten pluss et blikk på NAT-tabellen på serveren, fordi et økende antall sesjoner er det eneste direkte beviset på at oversettelsen skjer og ikke bare at den er slått på.

Noter deretter oppdelingen i designnotatet: hvilken komponent som leverer adressen, hvilken komponent som videresender, og hvilket vertsgrensesnitt trafikken går ut gjennom. Når en omstart endrer atferd, forteller notatet deg hvilken av de tre du skal undersøke i stedet for å starte alt på nytt og håpe at symptomet flytter seg.

Én avgjørelse til hører hjemme i protokollen, selv om du ikke tar den i dag: SecureNAT og en lokal bro er forskjellige design for den samme huben, og en hub som trenger begge er en hub som trenger en annen plan. Velg bevisst, skriv ned hvorfor, og neste person slipper å gjenskape det baklengs fra en kjørende konfigurasjon.