SoftEther SecureNAT: DHCP en NAT zijn twee beslissingen

SecureNAT is één selectievakje dat twee diensten inschakelt, en dat is de bron van de meeste verwarring erover. Een virtuele DHCP-server geeft de client een adres, een masker, een gateway en vaak een resolver. Een virtuele NAT stuurt pakketten voorbij die gateway met de eigen netwerkstack van de serverhost. Ze staan naast elkaar in de configuratie en falen onafhankelijk: een client kan een perfecte lease hebben en geen werkend pad, of een werkend pad met instellingen die naar de verkeerde resolver wijzen. Controleer ze als twee beslissingen, en de diagnose wordt kort.

Twee diensten achter één selectievakje

De virtuele DHCP-kant beantwoordt een configuratievraag: welke instellingen krijgt deze client binnen deze virtuele hub. De virtuele NAT-kant beantwoordt een doorstuurvraag: wanneer een client een pakket naar een adres buiten de hub stuurt, vertaalt en stuurt de server het dan door. Het eerste is lokaal voor de hub en heeft geen netwerk stroomopwaarts nodig. Het tweede hangt volledig van de host af.

De virtuele hostinterface hoort bij de eerste beslissing, niet bij de tweede. Het adres, vaak standaard iets als 192.168.30.1, is de gateway die de DHCP-dienst aanbiedt. Het is niet het openbare luisteradres van de server, en het verwarren van beide levert firewallregels en clientinstellingen op die gericht zijn op een machine die niet op dat netwerk bestaat.

Beslissing 1: wie levert het adres

Als de virtuele DHCP is ingeschakeld, horen clients een lease te krijgen in de pool die u hebt geconfigureerd, met de virtuele hostinterface als gateway en de resolver die u hebt opgegeven. Bekijk de lease en niet de statustekst van de client, want «verbonden» beschrijft de tunnel en niet de adrestoewijzing:

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

Twee faalmodi zijn de moeite waard om te kennen voordat u iets anders debugt. Een client met een achtergebleven statisch adres uit een eerder ontwerp houdt dat vast en negeert de lease, wat lijkt alsof DHCP weigert te antwoorden. En een tweede DHCP-bron op een overbrugd segment concurreert om dezelfde clients, wat wisselende adressen en een supportwachtrij oplevert die het probleem niet kan reproduceren.

Overlappende pools horen hier ook bij. Als de virtuele DHCP-pool overlapt met het LAN-subnet van de host of de pool van een andere hub, krijgt de client een adres dat dubbelzinnig wordt gerouteerd, en elke latere test is nietszeggend.

Beslissing 2: wie stuurt door voorbij de virtuele gateway

Met de virtuele NAT ingeschakeld vertaalt de server het uitgaande verkeer van de hub en stuurt het via de routingtabel van de host. Dat betekent dat de doorstuurkabel is: client naar virtuele gateway, virtuele NAT naar de stack van de host, de stack van de host naar zijn standaardroute. Elke schakel kan falen zonder de andere te raken, en de faalsignaturen verschillen.

Test de tweede beslissing met iets dat de hub moet verlaten, niet met iets dat er lokaal voor is. De virtuele gateway pingen bewijst de eerste schakel en niets meer:

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

Als naamresolutie werkt maar verbindingen naar een openbaar adres falen, zit u in de doorstuurkabel en niet in DHCP. Als beide falen, controleer dan eerst de resolver, want een resolver die als onbereikbaar intern adres wordt uitgedeeld, laat een werkend pad volledig kapot lijken.

De doorsturing van SecureNAT wordt door het serverproces uitgevoerd, niet door het kernel-doorstuurpad dat u met een bridge zou gebruiken. Dat is handig en langzamer dan bruggen, en het betekent ook dat de eigen firewallregels en routingbeslissingen van de host nog steeds gelden voor het vertaalde verkeer. De virtuele NAT omzeilt het beleid van de host niet; hij gebruikt het.

Het eigen pad van de host is een derde ding

Alles hierboven veronderstelt dat de serverhost de bestemming kan bereiken. Een host zonder werkende route stroomopwaarts, met een restrictief uitgaand beleid of met een adresfamilie die hij niet heeft, faalt op de tweede beslissing, hoe correct de hubconfiguratie ook is. Controleer de host apart, buiten de tunnel, voordat u zijn falen aan SoftEther toeschrijft.

SecureNAT is ook geen autorisatie om elk netwerk te bereiken dat aan de server is gekoppeld. Het vertaalt en stuurt verkeer door dat het bereikt; beslissen wat de host mag bereiken blijft het werk van de firewall en routing van de host, en een ontwerp dat op de tunnel vertrouwt om toegang te geven, is één slechte regel verwijderd van te veel geven.

Adresfamilies verdienen hun eigen controle. Een werkend IPv4 DHCP-voorbeeld bewijst niet dat elke IPv6-mogelijkheid in uw build aanwezig is, dus lees de handleiding voor de versie die u daadwerkelijk draait voordat u dual-stackgedrag belooft. De SecureNAT-sectie van de handleiding behandelt de virtuele NAT- en DHCP-functies voor de huidige release.

Controleer elke beslissing met zijn eigen test

Accepteer de eerste beslissing met een leasecontrole: adres in de pool, gateway gelijk aan de virtuele hostinterface, resolver degene die u hebt geconfigureerd. Accepteer de tweede met een uitgaand verzoek van de client plus een blik op de NAT-tabel op de server, want een stijgend aantal sessies is het enige directe bewijs dat de vertaling plaatsvindt en niet alleen dat hij is ingeschakeld.

Noteer daarna de splitsing in de ontwerpnotitie: welke component het adres levert, welke component doorstuurt en via welke hostinterface het verkeer naar buiten gaat. Wanneer een herstart het gedrag verandert, vertelt die notitie u welke van de drie u moet inspecteren in plaats van alles opnieuw te starten en te hopen dat het symptoom verschuift.

Nog één beslissing hoort in het verslag, ook als u die vandaag niet neemt: SecureNAT en een lokale bridge zijn verschillende ontwerpen voor dezelfde hub, en een hub die beide nodig heeft is een hub die een ander plan nodig heeft. Kies bewust, schrijf op waarom, en de volgende persoon hoeft het niet terug te reconstrueren uit een draaiende configuratie.