Ponte local do SoftEther ou SecureNAT: qual ativar

Abra o SoftEther Manager, e a primeira decisão real sobre um hub não é uma caixa de seleção, é uma questão de topologia. Uma ponte local liga esse hub a um adaptador físico e deixa o segmento existente fornecer o endereçamento, enquanto o SecureNAT dá ao hub o seu próprio router virtual, NAT e DHCP. Escolher entre os dois muda de onde vêm os endereços e qual dispositivo responde por eles. Ativar ambos e esperar que um ganhe é a forma como um laboratório que funciona se torna um tópico de suporte.

Comece pelo hub que está realmente a editar

O Manager mostra uma árvore de servidores e hubs, e é fácil configurar o hub predefinido enquanto os clientes se ligam a outro com um nome diferente. Clique no hub, leia o nome e confirme que as sessões listadas abaixo são os clientes que está a tentar servir. Essa única verificação evita a maior parte da confusão que depois é atribuída ao protocolo.

Depois decida o que o cliente precisa do extremo remoto. O comportamento Ethernet partilhado com difusão e serviços de LAN aponta para uma ponte, o acesso privado encaminhado para um pequeno intervalo de endereços aponta para o SecureNAT, e uma saída para a internet é uma decisão de encaminhamento que qualquer das disposições pode suportar mal.

Escreva a resposta antes de clicar em qualquer coisa, porque as duas definições não são intercambiáveis e desfazer leva mais tempo do que decidir. Dois minutos de escrita poupam uma hora de reconexões.

O que uma ponte local faz ao endereçamento

Uma ponte local liga o hub a um adaptador físico, pelo que o hub passa a fazer parte desse segmento Ethernet. Os clientes recebem endereços daquilo que já serve o segmento, e o seu gateway é o router do segmento. Do ponto de vista do cliente, juntou-se à LAN do escritório, com toda a acessibilidade e toda a exposição que isso implica.

Isso também significa que a ponte precisa de um adaptador real com o suporte de controlador adequado e que o administrador tem de estar autorizado a estender esse segmento. Um início de sessão VPN prova autenticação, não o direito de colocar um anfitrião numa VLAN de produção. Verifique se o nome do controlador corresponde ao adaptador pretendido, porque ligar a ponte à porta errada derruba um segmento rapidamente. Se a lista de adaptadores estiver vazia ou a ponte reportar uma falha, a resposta costuma estar relacionada com o controlador ou os privilégios e não com a criptografia.

Leia a tabela de pontes na linha de comandos quando a árvore gráfica for ambígua. A saída indica o adaptador, o que a árvore nem sempre faz.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Uma lista de pontes vazia com sessões ligadas é uma imagem útil: os clientes estão dentro do hub virtual e nada o está ainda a estender a um segmento.

O que o SecureNAT acrescenta e o que esconde

O SecureNAT dá ao hub um router virtual, uma função NAT e um serviço DHCP, tudo dentro do processo SoftEther. Os clientes recebem endereços do intervalo DHCP virtual, o router virtual responde pelo gateway predefinido e o tráfego que precisa de sair é traduzido. Não há qualquer adaptador físico envolvido, e é por isso que funciona num anfitrião com uma única placa de rede e sem configuração de comutador.

O custo é que os endereços virtuais pertencem ao hub e a mais nada. Uma máquina na LAN do escritório não pode encaminhar para o endereço SecureNAT de um cliente sem ajuda, e tudo o que registe endereços de origem vê o endereço traduzido do anfitrião SoftEther. Se as suas regras de acesso ou o seu rasto de auditoria dependem do endereço real do cliente, isso é uma alteração de conceção e não um detalhe. Também decide se uma regra de endereço de origem chegará a ver o cliente.

Também é um servidor DHCP. Executá-lo num segmento que já tem um, ou ligar a ponte nesse segmento ao mesmo tempo, produz dois respondedores e concessões imprevisíveis. O manual trata as duas funções como opções separadas exatamente por isso.

Inspecione o que o hub está a servir neste momento antes de ativar qualquer outra coisa. Cada comando imprime o estado atual e não o pretendido.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Ativar um sem quebrar o outro

Escolha a disposição, ative-a e deixe a outra desligada. Um hub com ponte e com SecureNAT ambos ativos é um hub com duas respostas possíveis para a mesma pergunta, e o cliente acreditará na que chegar primeiro. Quando migra de uma para a outra, desative a função antiga e volte a ligar o cliente em vez de assumir que a nova definição se aplica a uma sessão existente.

Ordene a alteração para que o conjunto de clientes não se sobreponha ao intervalo da LAN. As sub-redes sobrepostas são a segunda causa mais comum de um túnel que se liga e depois não alcança nada, e são invisíveis até comparar os dois planos de endereçamento lado a lado.

Depois volte a ligar a partir do cliente e leia o que recebeu, porque a visão do hub sobre a sessão não é a visão do cliente sobre a sua própria rede. Voltar a ligar é a única forma fiável de forçar uma concessão nova.

Verifique o gateway e o resolvedor no cliente

Uma autenticação bem-sucedida diz que as credenciais funcionam e que o hub aceitou a sessão. Não diz nada sobre se o cliente alcança alguma coisa, porque isso depende do endereço, da máscara, do gateway e do servidor DNS que recebeu. Leia esses quatro valores no cliente antes de voltar a tocar numa definição do servidor.

No Windows o detalhe do adaptador mostra a concessão e o resolvedor, e a tabela de rotas mostra se o túnel é realmente o caminho predefinido.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Num cliente Linux a mesma informação vem dos ficheiros de endereços, rotas e resolvedor. A rota predefinida é o valor que decide se o tráfego sai ou não pelo túnel. Se o gateway aponta para o router do escritório enquanto o túnel espera transportar o tráfego, a topologia está ligada por ponte em nome e quebrada na prática. Corrija primeiro a origem dos endereços, teste novamente a aplicação e só depois considere mudar o outro modo.