SoftEther SecureNAT: DHCP og NAT er to beslutninger

SecureNAT er ét flueben, der slår to tjenester til, og det er kilden til det meste af forvirringen omkring det. En virtuel DHCP-server giver klienten en adresse, en maske, en gateway og ofte en resolver. En virtuel NAT videresender pakker forbi den gateway ved hjælp af serverværtens egen netværksstak. De står ved siden af hinanden i konfigurationen og fejler uafhængigt: en klient kan have en perfekt lease og ingen fungerende vej, eller en fungerende vej med indstillinger, der peger på den forkerte resolver. Kontrollér dem som to beslutninger, og diagnosen bliver kort.

To tjenester bag ét flueben

DHCP-siden svarer på et konfigurationsspørgsmål: hvilke indstillinger får denne klient inde i denne virtuelle hub. NAT-siden svarer på et videresendelsesspørgsmål: når en klient sender en pakke til en adresse uden for hubben, oversætter og videresender serveren den så. Det første er lokalt for hubben og kræver intet netværk opad. Det andet afhænger helt af værten.

Den virtuelle værtsgrænseflade hører til den første beslutning, ikke den anden. Dens adresse, ofte noget i retning af 192.168.30.1 som standard, er den gateway, som DHCP-tjenesten tilbyder. Det er ikke serverens offentlige lytteadresse, og forveksling af de to giver firewallregler og klientindstillinger rettet mod en maskine, der ikke findes på det netværk.

Beslutning 1: hvem leverer adressen

Hvis den virtuelle DHCP er aktiveret, bør klienter modtage en lease i den pulje, du konfigurerede, med den virtuelle værtsgrænseflade som gateway og den resolver, du har angivet. Undersøg leasen i stedet for klientens statustekst, fordi »forbundet« beskriver tunnelen og ikke tildelingen af adresse:

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

To fejltilstande er værd at kende, før du fejlfinder noget andet. En klient med en resterende statisk adresse fra et tidligere design beholder den og ignorerer leasen, hvilket ser ud som om DHCP nægter at svare. Og en anden DHCP-kilde på et broet segment vil konkurrere om de samme klienter, hvilket giver periodiske adresser og en supportkø, der ikke kan genskabe problemet.

Overlappende puljer hører også hertil. Hvis den virtuelle DHCP-pulje overlapper værtens LAN-subnet eller en anden hubs pulje, får klienten en adresse, der rutes tvetydigt, og hver senere test er intetsigende.

Beslutning 2: hvem videresender forbi den virtuelle gateway

Med den virtuelle NAT aktiveret oversættes udgående trafik fra hubben af serveren og sendes gennem værtens routingtabel. Det betyder, at kæden er: klient til virtuel gateway, virtuel NAT til værtens stak, værtens stak til dens standardrute. Hvert led kan fejle uden at røre de andre, og fejlsignaturerne er forskellige.

Test den anden beslutning med noget, der skal forlade hubben, ikke med noget lokalt i den. At pinge den virtuelle gateway beviser det første led og intet mere:

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

Hvis navneopløsning virker, men forbindelser til en offentlig adresse fejler, er du i videresendelseskæden og ikke i DHCP. Hvis begge fejler, så tjek resolveren først, fordi en resolver, der skubbes ud som en uopnåelig intern adresse, får en fungerende vej til at se helt brudt ud.

SecureNATs videresendelse implementeres af serverprocessen, ikke af den kernelvideresendelsesvej, du ville bruge med en bro. Det er bekvemt og langsommere end at bro, og det betyder også, at værtens egne firewallregler og routingbeslutninger stadig gælder for den oversatte trafik. Den virtuelle NAT omgår ikke værtens politik; den bruger den.

Værtens egen vej er en tredje ting

Alt ovenstående forudsætter, at serverværten kan nå destinationen. En vært uden en fungerende rute opad, med en restriktiv udgående politik eller med en adressefamilie, som værten ikke har, vil fejle den anden beslutning, uanset hvor korrekt hubkonfigurationen er. Kontrollér værten for sig selv, uden for tunnelen, før du tilskriver dens fejl til SoftEther.

SecureNAT er heller ikke en tilladelse til at nå hvert netværk, der er knyttet til serveren. Det oversætter og videresender trafik, der når det; at afgøre, hvad værten må nå, er stadig værtens firewall- og routingarbejde, og et design, der regner med tunnelen til at give adgang, er én dårlig regel fra at give for meget.

Adressefamilier fortjener deres egen kontrol. Et fungerende IPv4 DHCP-eksempel beviser ikke, at enhver IPv6-evne findes i dit byg, så læs manualen for den version, du faktisk kører, før du lover dobbeltstak-adfærd. SecureNAT-afsnittet i manualen dækker de virtuelle NAT- og DHCP-funktioner for den aktuelle udgivelse.

Kontrollér hver beslutning med sin egen test

Accepter den første beslutning med en leasekontrol: adresse i puljen, gateway lig den virtuelle værtsgrænseflade, resolver den, du konfigurerede. Accepter den anden med en udgående anmodning fra klienten plus et kig på NAT-tabellen på serveren, fordi et stigende antal sessioner er det eneste direkte bevis på, at oversættelsen sker, og ikke blot at den er slået til.

Notér derefter opdelingen i designnotatet: hvilken komponent der leverer adressen, hvilken komponent der videresender, og hvilken værtsgrænseflade trafikken forlader gennem. Når en genstart ændrer adfærd, fortæller notatet dig, hvilken af de tre du skal undersøge, i stedet for at genstarte alt og håbe på, at symptomet flytter sig.

En beslutning mere hører til i optegnelsen, selv om du ikke træffer den i dag: SecureNAT og en lokal bro er forskellige design til den samme hub, og en hub, der har brug for begge, er en hub, der har brug for en anden plan. Vælg bevidst, skriv hvorfor, og den næste person behøver ikke at reverse-engineere det ud fra en kørende konfiguration.