O que um hub virtual do SoftEther realmente liga

O hub virtual do SoftEther é uma fronteira de associação dentro de um servidor, não um local. As sessões que se associam ao hub alcançam aquilo a que o hub está ligado, e as sessões noutro hub não conseguem, mesmo quando ambas se autenticam no mesmo servidor. Por isso, um início de sessão bem-sucedido ainda pode colocar um cliente na rede errada. Ler o hub como um switch virtual esclarece o que ele faz e o que deixa à ponte, ao encaminhamento e à configuração em cascata.

Um hub é uma fronteira de associação

Um servidor pode alojar vários hubs, cada um com os seus próprios utilizadores, sessões e política. A autenticação estabelece quem é a sessão, enquanto o hub decide a que rede virtual essa sessão se associa. Dois hubs no mesmo anfitrião comportam-se, por isso, como dois switches separados que partilham hardware por acaso. Nada num início de sessão bem-sucedido implica que a sessão aterrou onde queria.

Utilize o nome de hub documentado pelo operador em vez de um nome recordado de uma captura de ecrã. Um cliente que se associa ao hub errado alcança outra rede com uma credencial válida, o que é uma constatação de configuração e não uma falha de segurança. Guarde o nome do hub e o seu propósito nas notas do perfil de ligação.

A administração é delimitada da mesma forma. Um administrador de hub gere esse hub, enquanto o administrador do servidor gere o processo, os ouvintes e cada hub no anfitrião.

As ligações decidem o que está do outro lado

Um hub por si só liga as sessões entre si. Alcançar qualquer outra coisa depende de como o hub está ligado: uma ponte local para uma interface física, um router virtual ou uma cascata para outro servidor. Cada ligação traz as suas próprias regras de reencaminhamento e os seus próprios modos de falha. Supor que um hub fornece acesso à internet é o erro mais comum sobre o produto.

O SecureNAT é a opção integrada, implementada com um router virtual e um serviço DHCP virtual dentro do servidor. É cómoda para um laboratório e incómoda para tudo o que precise de endereçamento ou política previsíveis. Uma ponte local coloca o hub num segmento real, que herda a comutação, o DHCP e o comportamento de difusão desse segmento.

Uma cascata liga dois servidores para que as sessões de um hub possam aparecer no outro. É uma relação de hub para hub, por isso ambos os extremos precisam de política compatível e de um caminho funcional entre eles.

Leia as sessões e a política separadamente

As vistas de sessões, endereços MAC e endereços IP descrevem como a rede virtual está agora. São observações, não permissões. Uma sessão visível na lista não fica por isso autorizada a todos os serviços a que o hub pode chegar, e o contrário também se aplica.

Compare a lista de sessões com a política que lhe deveria ser aplicada. Um dispositivo com um endereço fora do intervalo pretendido significa normalmente DHCP de outro lugar ou um cliente configurado à mão. Um endereço MAC que se desloca entre sessões significa um dispositivo migrado ou dois dispositivos que partilham uma identidade. Ambos merecem uma olhadela, e nenhum é provado apenas pela tabela.

No servidor, vpncmd relata a mesma imagem do ponto de vista do anfitrião. Compare essa saída com a vista do próprio cliente sempre que as duas discordem.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Trate a administração do hub como um papel próprio e não como uma permissão de cliente. Delegar um hub não deveria entregar os ouvintes nem o processo que aloja todos os outros hubs.

Verifique o cliente após a associação

Do lado do cliente, uma sessão estabelecida prova apenas que a autenticação e o nome do hub foram aceites. Confirme o endereço, a rota e a resolução de nomes separadamente, porque cada uma pode falhar depois de o hub aceitar a sessão.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

A lista de endereços mostra se o adaptador recebeu uma concessão da fonte pretendida. A consulta de rota mostra que interface transportaria um destino privado, e a consulta ao resolver mostra se o DNS seguiu a sessão. Um hub que reencaminha pacotes enquanto o DNS ainda aponta para a rede local produz a clássica ligação meio a funcionar.

Teste a aplicação e não a ligação. Uma página de intranet que carrega é uma prova mais forte do que um adaptador com um endereço plausível.