SoftEther SecureNAT: DHCP i NAT són dues decisions

SecureNAT és una única casella que activa dos serveis, i això és l’origen de la major part de la confusió que l’envolta. Un servidor DHCP virtual lliura al client una adreça, una màscara, una passarel·la i sovint un resolutor. Un NAT virtual encamina els paquets més enllà d’aquesta passarel·la amb la pròpia pila de xarxa de l’amfitrió del servidor. Tots dos conviuen a la configuració i fallen de manera independent: un client pot tenir una concessió perfecta i cap camí operatiu, o un camí operatiu amb paràmetres que apunten al resolutor equivocat. Verifica’ls com a dues decisions i el diagnòstic es fa curt.

Dos serveis darrere d’una casella

El costat del DHCP virtual respon una pregunta de configuració: quins paràmetres rep aquest client dins d’aquest concentrador virtual. El costat del NAT virtual respon una pregunta de reenviament: quan un client envia un paquet a una adreça fora del concentrador, el servidor el tradueix i el reenvia. El primer és local al concentrador i no necessita cap xarxa superior. El segon depèn completament de l’amfitrió.

La interfície d’amfitrió virtual pertany a la primera decisió, no a la segona. La seva adreça, sovint una cosa com 192.168.30.1 per defecte, és la passarel·la que ofereix el servei DHCP. No és l’adreça pública d’escolta del servidor, i confondre les dues produeix regles de tallafoc i paràmetres de client dirigits a una màquina que no existeix en aquella xarxa.

Decisió 1: qui subministra l’adreça

Si el DHCP virtual està activat, els clients haurien de rebre una concessió dins del pool que has configurat, amb la interfície d’amfitrió virtual com a passarel·la i el resolutor que hagis subministrat. Inspecciona la concessió i no el text d’estat del client, perquè «connectat» descriu el túnel i no l’assignació d’adreça:

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

Hi ha dos modes de fallada que val la pena conèixer abans de depurar cap altra cosa. Un client amb una adreça estàtica residual d’un disseny anterior la conservarà i ignorarà la concessió, cosa que sembla que el DHCP es negui a respondre. I un segon origen DHCP en un segment pontitzat competirà pels mateixos clients, cosa que produeix adreces intermitents i una cua de suport que no pot reproduir el problema.

Els pools superposats també hi tenen lloc. Si el pool del DHCP virtual se superposa a la subxarxa LAN de l’amfitrió o al pool d’un altre concentrador, el client rep una adreça que encamina de manera ambigua, i cada prova posterior és inconcloent.

Decisió 2: qui reenvia més enllà de la passarel·la virtual

Amb el NAT virtual activat, el trànsit de sortida del concentrador el tradueix el servidor i el tramet per la taula d’encaminament de l’amfitrió. Això vol dir que la cadena de reenviament és: client a passarel·la virtual, NAT virtual a pila de l’amfitrió, pila de l’amfitrió a la seva ruta per defecte. Cada enllaç pot fallar sense tocar els altres, i les signatures de fallada són diferents.

Prova la segona decisió amb una cosa que hagi de sortir del concentrador, no amb una cosa local a ell. Fer ping a la passarel·la virtual demostra el primer enllaç i res més:

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

Si la resolució de noms funciona però les connexions a una adreça pública fallen, ets a la cadena de reenviament i no al DHCP. Si fallen totes dues, comprova primer el resolutor, perquè un resolutor empès com a adreça interna inabastable farà que un camí operatiu sembli completament trencat.

El reenviament de SecureNAT l’implementa el procés del servidor, no el camí de reenviament del nucli que faries servir amb un pont. Això és còmode i més lent que fer pont, i també vol dir que les regles de tallafoc i les decisions d’encaminament de l’amfitrió segueixen aplicant-se al trànsit traduït. El NAT virtual no eludeix la política de l’amfitrió; la utilitza.

El camí propi de l’amfitrió és una tercera cosa

Tot l’anterior pressuposa que l’amfitrió del servidor pot arribar a la destinació. Un amfitrió sense ruta superior operativa, amb una política de sortida restrictiva o amb una família d’adreces que no té fallarà la segona decisió per correcta que sigui la configuració del concentrador. Comprova l’amfitrió pel seu compte, fora del túnel, abans d’atribuir la seva fallada a SoftEther.

SecureNAT tampoc no és una autorització per arribar a cada xarxa connectada al servidor. Tradueix i reenvia el trànsit que li arriba; decidir a què pot arribar l’amfitrió continua sent feina del tallafoc i de l’encaminament de l’amfitrió, i un disseny que confia en el túnel per concedir accés és a una regla dolenta de concedir-ne massa.

Les famílies d’adreces mereixen la seva pròpia comprovació. Un exemple de DHCP IPv4 que funciona no estableix que tota capacitat IPv6 sigui present a la teva compilació, així que llegeix el manual de la versió que realment executes abans de prometre comportament de doble pila. La secció SecureNAT del manual cobreix les funcions de NAT i DHCP virtuals per a la versió actual.

Verifica cada decisió amb la seva pròpia prova

Accepta la primera decisió amb una comprovació de la concessió: adreça dins del pool, passarel·la igual a la interfície d’amfitrió virtual, resolutor el que vas configurar. Accepta la segona amb una petició de sortida des del client i una mirada a la taula NAT del servidor, perquè un recompte de sessions creixent és l’única evidència directa que la traducció s’està produint i no només que està activada.

Després anota la separació a la nota de disseny: quin component subministra l’adreça, quin component reenvia i per quina interfície d’amfitrió surt el trànsit. Quan un reinici canviï el comportament, aquella nota et diu quin dels tres cal inspeccionar en comptes de reiniciar-ho tot i esperar que el símptoma es mogui.

Una decisió més pertany a l’expedient, encara que avui no la prenguis: SecureNAT i un pont local són dissenys diferents per al mateix concentrador, i un concentrador que necessita tots dos és un concentrador que necessita un altre pla. Tria conscientment, escriu per què, i la propera persona no haurà de fer enginyeria inversa a partir d’una configuració en marxa.