Abra SoftEther Manager e a primeira decisión real sobre un hub non é unha caixa de verificación, é unha cuestión de topoloxía. Unha ponte local conecta ese hub a un adaptador físico e deixa que o segmento existente proporcione o enderezamento, mentres que SecureNAT dálle ao hub o seu propio router virtual, NAT e DHCP. Escoller entre ambos cambia de onde veñen os enderezos e que dispositivo responde por eles. Activar os dous e esperar que un gañe é a forma en que un laboratorio que funciona se converte nun fío de soporte.

Comece polo hub que está a editar de verdade

Manager mostra unha árbore de servidores e hubs, e é fácil configurar o hub predeterminado mentres os clientes se conectan a outro cun nome distinto. Faga clic no hub, lea o seu nome e confirme que as sesións que aparecen debaixo son os clientes que intenta atender. Esa única comprobación evita a maior parte da confusión que despois se atribúe ao protocolo.

Despois decida que necesita o cliente do extremo remoto. O comportamento Ethernet compartido con difusión e servizos LAN apunta a unha ponte, o acceso privado encamiñado a un rango pequeno de enderezos apunta a SecureNAT, e unha saída a internet é unha decisión de encamiñamento que calquera das dúas disposicións pode levar mal.

Escriba a resposta antes de facer clic en nada, porque os dous axustes non son intercambiables e desfacer leva máis tempo que decidir. Dous minutos de escritura aforran unha hora de reconexións.

Que fai unha ponte local co enderezamento

Unha ponte local conecta o hub a un adaptador físico, así que o hub pasa a formar parte dese segmento Ethernet. Os clientes reciben enderezos do que xa serve o segmento, e a súa porta de enlace é o router do segmento. Desde o punto de vista do cliente, uniuse á LAN da oficina, con toda a accesibilidade e toda a exposición que iso implica.

Iso tamén significa que a ponte necesita un adaptador real co soporte de controlador axeitado e que o administrador debe estar autorizado a estender ese segmento. Un inicio de sesión VPN demostra autenticación, non o dereito a colocar un host nunha VLAN de produción. Comprobe que o nome do controlador coincide co adaptador que pretende, porque poñer unha ponte no porto equivocado tira un segmento abaixo rapidamente. Se a lista de adaptadores está baleira ou a ponte informa dun fallo, a resposta normalmente ten que ver co controlador ou cos privilexios, non coa criptografía.

Lea a táboa de pontes desde a liña de ordes cando a árbore gráfica sexa ambigua. A saída nomea o adaptador, cousa que a árbore non sempre fai.

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

Unha lista de pontes baleira con sesións conectadas é unha imaxe útil: os clientes están dentro do hub virtual e nada o estende aínda a un segmento.

Que engade SecureNAT e que oculta

SecureNAT dálle ao hub un router virtual, unha función NAT e un servizo DHCP, todo dentro do proceso de SoftEther. Os clientes obteñen enderezos do rango DHCP virtual, o router virtual responde pola porta de enlace predeterminada e o tráfico que precisa saír tradúcese. Non intervén ningún adaptador físico, e por iso funciona nun host cunha soa tarxeta de rede e sen configuración de conmutador.

O custo é que os enderezos virtuais pertencen ao hub e a nada máis. Unha máquina da LAN da oficina non pode encamiñar cara ao enderezo SecureNAT dun cliente sen axuda, e todo o que rexistra enderezos de orixe ve o enderezo traducido do host de SoftEther. Se as súas regras de acceso ou o seu rastro de auditoría dependen do enderezo real do cliente, iso é un cambio de deseño e non un detalle. Tamén decide se unha regra de enderezo de orixe chegará a ver o cliente.

Tamén é un servidor DHCP. Executalo nun segmento que xa ten un, ou poñer unha ponte nese segmento ao mesmo tempo, produce dous respondedores e concesións impredicibles. O manual trata as dúas funcións como opcións separadas exactamente por iso.

Inspeccione que está servindo o hub agora mesmo antes de activar calquera outra cousa. Cada orde imprime o estado actual, non o previsto.

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

Activar un sen romper o outro

Escolla a disposición, actívea e deixe a outra apagada. Un hub con ponte e con SecureNAT ambos activos é un hub con dúas respostas posibles á mesma pregunta, e o cliente crerá a que chegue primeiro. Cando migre dunha á outra, desactive a función antiga e volva conectar o cliente en lugar de supoñer que o novo axuste actúa sobre unha sesión existente.

Ordene o cambio de xeito que o conxunto de clientes non se solape co rango da LAN. As subredes solapadas son a segunda causa máis común dun túnel que se conecta e despois non alcanza nada, e son invisibles ata que compara os dous plans de enderezamento lado a lado.

Despois volva conectar desde o cliente e lea que recibiu, porque a visión do hub sobre a sesión non é a visión do cliente sobre a súa propia rede. Reconectar é a única forma fiable de forzar unha concesión nova.

Comprobe a porta de enlace e o resolvedor no cliente

Unha autenticación correcta di que as credenciais funcionan e que o hub aceptou a sesión. Non di nada sobre se o cliente alcanza algo, porque iso depende do enderezo, da máscara, da porta de enlace e do servidor DNS que recibiu. Lea eses catro valores no cliente antes de tocar de novo un axuste do servidor.

En Windows o detalle do adaptador mostra a concesión e o resolvedor, e a táboa de rutas mostra se o túnel é realmente a ruta predeterminada.

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

Nun cliente Linux a mesma información vén dos ficheiros de enderezos, rutas e resolvedor. A ruta predeterminada é o valor que decide se o tráfico sae ou non polo túnel. Se a porta de enlace apunta ao router da oficina mentres o túnel espera transportar o tráfico, a topoloxía está pontada de nome e rota na práctica. Corrixa primeiro a orixe dos enderezos, volva probar a aplicación e só entón considere cambiar o outro modo.

Artigos relacionados