SoftEther SecureNAT: DHCP e NAT são duas decisões

O SecureNAT é uma única caixa de seleção que ativa dois serviços, e é daí que vem a maior parte da confusão em torno dele. Um servidor DHCP virtual entrega ao cliente um endereço, uma máscara, um gateway e muitas vezes um resolver. Um NAT virtual encaminha pacotes para além desse gateway usando a própria pilha de rede do host do servidor. Os dois ficam lado a lado na configuração e falham de forma independente: um cliente pode ter uma concessão perfeita e nenhum caminho funcional, ou um caminho funcional com definições que apontam para o resolver errado. Verifique-os como duas decisões e o diagnóstico fica curto.

Dois serviços atrás de uma caixa de seleção

O lado do DHCP virtual responde a uma pergunta de configuração: que definições este cliente recebe dentro deste concentrador virtual. O lado do NAT virtual responde a uma pergunta de encaminhamento: quando um cliente envia um pacote para um endereço fora do concentrador, o servidor traduz e encaminha. O primeiro é local ao concentrador e não precisa de rede a montante. O segundo depende inteiramente do host.

A interface de host virtual pertence à primeira decisão, não à segunda. O seu endereço, muitas vezes algo como 192.168.30.1 por omissão, é o gateway que o serviço DHCP oferece. Não é o endereço público de escuta do servidor, e confundir os dois produz regras de firewall e definições de cliente dirigidas a uma máquina que não existe nessa rede.

Decisão 1: quem fornece o endereço

Se o DHCP virtual estiver ativo, os clientes devem receber uma concessão no conjunto que configurou, com a interface de host virtual como gateway e o resolver que forneceu. Inspecione a concessão e não o texto de estado do cliente, porque «ligado» descreve o túnel e não a atribuição de endereço:

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

Há dois modos de falha que vale a pena conhecer antes de depurar qualquer outra coisa. Um cliente com um endereço estático residual de um desenho anterior irá mantê-lo e ignorar a concessão, o que parece que o DHCP se recusa a responder. E uma segunda fonte DHCP num segmento com ponte vai competir pelos mesmos clientes, o que produz endereços intermitentes e uma fila de suporte que não consegue reproduzir o problema.

Os conjuntos sobrepostos também têm lugar aqui. Se o conjunto do DHCP virtual se sobrepuser à sub-rede LAN do host ou ao conjunto de outro concentrador, o cliente recebe um endereço que é encaminhado de forma ambígua, e cada teste posterior é inconclusivo.

Decisão 2: quem encaminha para além do gateway virtual

Com o NAT virtual ativo, o tráfego de saída do concentrador é traduzido pelo servidor e enviado pela tabela de encaminhamento do host. Isso significa que a cadeia de encaminhamento é: cliente para o gateway virtual, NAT virtual para a pilha do host, pilha do host para a sua rota por omissão. Cada elo pode falhar sem tocar nos outros, e as assinaturas de falha são diferentes.

Teste a segunda decisão com algo que tenha de sair do concentrador, não com algo que lhe seja local. Fazer ping ao gateway virtual prova o primeiro elo e nada mais:

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

Se a resolução de nomes funciona mas as ligações a um endereço público falham, está na cadeia de encaminhamento e não no DHCP. Se ambas falham, verifique primeiro o resolver, porque um resolver fornecido como endereço interno inalcançável fará um caminho funcional parecer completamente quebrado.

O encaminhamento do SecureNAT é implementado pelo processo do servidor, não pelo caminho de encaminhamento do kernel que usaria com uma ponte. Isso é conveniente e mais lento do que fazer ponte, e também significa que as regras de firewall e as decisões de encaminhamento do host continuam a aplicar-se ao tráfego traduzido. O NAT virtual não contorna a política do host; usa-a.

O caminho próprio do host é uma terceira coisa

Tudo o que acima se disse pressupõe que o host do servidor consegue alcançar o destino. Um host sem rota a montante funcional, com uma política de saída restritiva ou com uma família de endereços que não tem falhará a segunda decisão, por mais correta que seja a configuração do concentrador. Verifique o host por si só, fora do túnel, antes de atribuir a sua falha ao SoftEther.

O SecureNAT também não é uma autorização para alcançar cada rede ligada ao servidor. Traduz e encaminha o tráfego que chega até ele; decidir a que o host pode chegar continua a ser trabalho da firewall e do encaminhamento do host, e um desenho que conta com o túnel para conceder acesso está a uma má regra de conceder demasiado.

As famílias de endereços merecem verificação própria. Um exemplo de DHCP IPv4 a funcionar não estabelece que toda a capacidade IPv6 esteja presente na sua compilação, por isso leia o manual da versão que realmente executa antes de prometer comportamento de pilha dupla. A secção SecureNAT do manual cobre as funções de NAT e DHCP virtuais para a versão atual.

Verifique cada decisão com o seu próprio teste

Aceite a primeira decisão com uma verificação da concessão: endereço no conjunto, gateway igual à interface de host virtual, resolver o que configurou. Aceite a segunda com um pedido de saída do cliente e uma vista da tabela NAT no servidor, porque uma contagem de sessões a subir é a única prova direta de que a tradução está a acontecer e não apenas de que está ativa.

Depois registe a separação na nota de desenho: que componente fornece o endereço, que componente encaminha e por que interface de host o tráfego sai. Quando um reinício alterar o comportamento, essa nota diz-lhe qual dos três inspecionar em vez de reiniciar tudo e esperar que o sintoma se desloque.

Mais uma decisão pertence ao registo, mesmo que hoje não a tome: o SecureNAT e uma ponte local são desenhos diferentes para o mesmo concentrador, e um concentrador que precisa de ambos é um concentrador que precisa de outro plano. Escolha deliberadamente, escreva porquê, e a próxima pessoa não terá de fazer engenharia inversa a partir de uma configuração em execução.