SoftEther SecureNAT: DHCP och NAT är två beslut

SecureNAT är en enda kryssruta som slår på två tjänster, och det är källan till det mesta av förvirringen kring det. En virtuell DHCP-server ger klienten en adress, en mask, en gateway och ofta en resolver. En virtuell NAT skickar paket förbi den gatewayen med hjälp av servervärdens egen nätverksstack. De står bredvid varandra i konfigurationen och misslyckas oberoende av varandra: en klient kan ha ett perfekt lån och ingen fungerande väg, eller en fungerande väg med inställningar som pekar på fel resolver. Kontrollera dem som två beslut, och diagnosen blir kort.

Två tjänster bakom en kryssruta

DHCP-sidan svarar på en konfigurationsfråga: vilka inställningar får den här klienten inne i den här virtuella hubben. NAT-sidan svarar på en vidarebefordringsfråga: när en klient skickar ett paket till en adress utanför hubben, översätter och vidarebefordrar servern det. Det första är lokalt för hubben och behöver inget nätverk uppströms. Det andra beror helt på värden.

Det virtuella värdgränssnittet hör till det första beslutet, inte det andra. Dess adress, ofta något i stil med 192.168.30.1 som standard, är den gateway som DHCP-tjänsten erbjuder. Det är inte serverns offentliga lyssnaradress, och att blanda ihop de två ger brandväggsregler och klientinställningar riktade mot en maskin som inte finns på det nätverket.

Beslut 1: vem som levererar adressen

Om den virtuella DHCP:n är påslagen bör klienter få ett lån i den pool du konfigurerade, med det virtuella värdgränssnittet som gateway och den resolver du angav. Granska lånet och inte klientens statustext, eftersom «ansluten» beskriver tunneln och inte adresstilldelningen:

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

Två felmoder är värda att känna till innan du felsöker något annat. En klient med en kvarvarande statisk adress från en tidigare design behåller den och ignorerar lånet, vilket ser ut som om DHCP vägrar svara. Och en andra DHCP-källa på ett bryggat segment konkurrerar om samma klienter, vilket ger sporadiska adresser och en supportkö som inte kan återskapa problemet.

Överlappande pooler hör också hemma här. Om den virtuella DHCP-poolen överlappar värdens LAN-subnät eller en annan hubs pool får klienten en adress som routas tvetydigt, och varje senare test är intetsägande.

Beslut 2: vem som vidarebefordrar förbi den virtuella gatewayen

Med den virtuella NAT:n påslagen översätts utgående trafik från hubben av servern och skickas genom värdens routingtabell. Det betyder att vidarebefordringskedjan är: klient till virtuell gateway, virtuell NAT till värdens stack, värdens stack till dess standardrutt. Varje länk kan misslyckas utan att röra de andra, och felsignaturerna skiljer sig.

Testa det andra beslutet med något som måste lämna hubben, inte med något som är lokalt för den. Att pinga den virtuella gatewayen bevisar den första länken och inget mer:

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

Om namnmatchning fungerar men anslutningar till en offentlig adress misslyckas, är du i vidarebefordringskedjan och inte i DHCP. Om båda misslyckas, kontrollera resolvern först, eftersom en resolver som skickas ut som en oåtkomlig intern adress får en fungerande väg att se helt trasig ut.

SecureNAT:s vidarebefordran implementeras av serverprocessen, inte av den kernelvidarebefordringsväg du skulle använda med en brygga. Det är bekvämt och långsammare än att brygga, och det innebär också att värdens egna brandväggsregler och routingbeslut fortfarande gäller för den översatta trafiken. Den virtuella NAT:n kringgår inte värdens policy; den använder den.

Värdens egen väg är en tredje sak

Allt ovan förutsätter att servervärden kan nå målet. En värd utan fungerande rutt uppströms, med en restriktiv utgående policy eller med en adressfamilj den inte har, kommer att misslyckas med det andra beslutet, hur korrekt hubkonfigurationen än är. Kontrollera värden för sig själv, utanför tunneln, innan du tillskriver felet SoftEther.

SecureNAT är inte heller ett tillstånd att nå varje nätverk som är anslutet till servern. Det översätter och vidarebefordrar trafik som når det; att avgöra vad värden får nå är fortfarande värdens brandväggs- och routingarbete, och en design som förlitar sig på tunneln för att ge åtkomst är en dålig regel från att ge för mycket.

Adressfamiljer förtjänar sin egen kontroll. Ett fungerande IPv4 DHCP-exempel fastställer inte att varje IPv6-förmåga finns i ditt bygge, så läs manualen för den version du faktiskt kör innan du lovar dual-stack-beteende. SecureNAT-avsnittet i manualen täcker de virtuella NAT- och DHCP-funktionerna för den aktuella utgåvan.

Kontrollera varje beslut med dess egen test

Acceptera det första beslutet med en lånekontroll: adress i poolen, gateway lika med det virtuella värdgränssnittet, resolver den du konfigurerade. Acceptera det andra med en utgående begäran från klienten plus en titt på NAT-tabellen på servern, eftersom ett ökande antal sessioner är det enda direkta beviset på att översättningen sker och inte bara att den är påslagen.

Anteckna sedan uppdelningen i designanteckningen: vilken komponent som levererar adressen, vilken komponent som vidarebefordrar och vilket värdgränssnitt trafiken går ut genom. När en omstart ändrar beteendet berättar anteckningen vilken av de tre du ska undersöka i stället för att starta om allt och hoppas att symptomet flyttar sig.

Ett beslut till hör hemma i protokollet, även om du inte fattar det i dag: SecureNAT och en lokal brygga är olika designer för samma hubb, och en hubb som behöver båda är en hubb som behöver en annan plan. Välj medvetet, skriv ner varför, och nästa person slipper återskapa det baklänges från en körande konfiguration.