SoftEther SecureNAT: DHCP e NAT son dúas decisións

SecureNAT é unha única caixa que activa dous servizos, e de aí vén a maior parte da confusión que o rodea. Un servidor DHCP virtual entrega ao cliente un enderezo, unha máscara, unha pasarela e a miúdo un resolutor. Un NAT virtual reenvía paquetes máis alá desa pasarela usando a propia pila de rede do host do servidor. Ambos conviven na configuración e fallan de forma independente: un cliente pode ter unha concesión perfecta e ningunha ruta funcional, ou unha ruta funcional con axustes que apuntan ao resolutor equivocado. Verifícaos como dúas decisións e o diagnóstico vólvese curto.

Dous servizos detrás dunha caixa

O lado do DHCP virtual responde a unha pregunta de configuración: que axustes recibe este cliente dentro deste concentrador virtual. O lado do NAT virtual responde a unha pregunta de reenvío: cando un cliente envía un paquete a un enderezo fóra do concentrador, o servidor tradúceo e reenvíao. O primeiro é local ao concentrador e non necesita ningunha rede augas arriba. O segundo depende por completo do host.

A interface de host virtual pertence á primeira decisión, non á segunda. O seu enderezo, a miúdo algo como 192.168.30.1 por defecto, é a pasarela que ofrece o servizo DHCP. Non é o enderezo público de escoita do servidor, e confundir ambos produce regras de devasas e axustes de cliente dirixidos a unha máquina que non existe nesa rede.

Decisión 1: quen subministra o enderezo

Se o DHCP virtual está activado, os clientes deberían recibir unha concesión no grupo que configurases, coa interface de host virtual como pasarela e o resolutor que proporcionases. Inspecciona a concesión e non o texto de estado do cliente, porque «conectado» describe o túnel e non a asignación de enderezo:

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

Paga a pena coñecer dous modos de fallo antes de depurar calquera outra cousa. Un cliente cun enderezo estático residual dun deseño anterior conservarao e ignorará a concesión, o que parece que o DHCP se nega a responder. E unha segunda fonte DHCP nun segmento con ponte competirá polos mesmos clientes, o que produce enderezos intermitentes e unha cola de soporte que non pode reproducir o problema.

Os grupos superpostos tamén teñen cabida aquí. Se o grupo do DHCP virtual se superpón á subrede LAN do host ou ao grupo doutro concentrador, o cliente recibe un enderezo que encamiña de forma ambigua, e cada proba posterior é inconcluínte.

Decisión 2: quen reenvía máis alá da pasarela virtual

Co NAT virtual activado, o tráfico de saída do concentrador tradúceo o servidor e envíase pola táboa de encamiñamento do host. Iso significa que a cadea de reenvío é: cliente a pasarela virtual, NAT virtual a pila do host, pila do host á súa ruta por defecto. Cada elo pode fallar sen tocar os demais, e as sinaturas de fallo son distintas.

Proba a segunda decisión con algo que deba saír do concentrador, non con algo local a el. Facer ping á pasarela virtual demostra o primeiro elo e nada máis:

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

Se a resolución de nomes funciona pero as conexións a un enderezo público fallan, estás na cadea de reenvío e non no DHCP. Se fallan ambas, comproba primeiro o resolutor, porque un resolutor empuxado como enderezo interno inalcanzable fará que unha ruta funcional pareza completamente rota.

O reenvío de SecureNAT impleméntao o proceso do servidor, non a ruta de reenvío do núcleo que usarías cunha ponte. Iso é cómodo e máis lento que facer ponte, e tamén significa que as regras de devasas e as decisións de encamiñamento do host seguen aplicándose ao tráfico traducido. O NAT virtual non elude a política do host; utilízaa.

A ruta propia do host é unha terceira cousa

Todo o anterior presupón que o host do servidor pode alcanzar o destino. Un host sen ruta funcional augas arriba, cunha política de saída restritiva ou cunha familia de enderezos que non ten fallará a segunda decisión por correcta que sexa a configuración do concentrador. Comproba o host por separado, fóra do túnel, antes de atribuír o seu fallo a SoftEther.

SecureNAT tampouco é unha autorización para alcanzar cada rede conectada ao servidor. Traduce e reenvía o tráfico que lle chega; decidir a que pode chegar o host segue sendo traballo da devasa e do encamiñamento do host, e un deseño que confía no túnel para conceder acceso está a unha regra mala de conceder demasiado.

As familias de enderezos merecen a súa propia comprobación. Un exemplo de DHCP IPv4 que funciona non establece que toda capacidade IPv6 estea presente na túa compilación, así que le o manual da versión que realmente executas antes de prometer comportamento de dobre pila. A sección SecureNAT do manual cobre as funcións de NAT e DHCP virtuais para a versión actual.

Verifica cada decisión coa súa propia proba

Acepta a primeira decisión cunha comprobación da concesión: enderezo no grupo, pasarela igual á interface de host virtual, resolutor o que configurases. Acepta a segunda cunha petición de saída desde o cliente e unha ollada á táboa NAT do servidor, porque un reconto de sesións crecente é a única evidencia directa de que a tradución ocorre e non só de que está activada.

Despois anota a separación na nota de deseño: que compoñente subministra o enderezo, que compoñente reenvía e por que interface de host sae o tráfico. Cando un reinicio cambie o comportamento, esa nota diche cal dos tres inspeccionar en vez de reinicialo todo e esperar que o síntoma se mova.

Unha decisión máis pertence ao rexistro, aínda que hoxe non a tomes: SecureNAT e unha ponte local son deseños distintos para o mesmo concentrador, e un concentrador que necesita ambos é un concentrador que necesita outro plan. Escolle a conciencia, escribe por que, e a próxima persoa non terá que facer enxeñaría inversa a partir dunha configuración en marcha.