Ese enderezo de túnel é un par, non unha subrede que poidas explorar

O teu cliente conéctase e mostra un par de enderezos, ou un só enderezo cunha 255.255.255.255 máscara, e a primeira reacción é que o servidor entregou algo roto. Nada está roto: unha interface tunelada é unha ligazón punto a punto, e a máscara describe o extremo remoto desa única ligazón, non un rango de veciños. Ler o par como local e par explica a máscara estraña, a ruta dun só host ao seu carón e a táboa de veciños ausente. O que a mesma lectura non escusa é un plan de enderezos que se solapa coa rede da oficina.

Por que a máscara parece incorrecta nunha ligazón tunelada

Nunha interface Ethernet, un enderezo e unha máscara afirman dúas cousas: este host posúe o enderezo, e todo o que está dentro do prefixo é un veciño directo. O núcleo deriva unha ruta na ligazón a partir deses dous feitos e despois resolve enderezos de ligazón para os veciños que cre presentes. Unha interface punto a punto conserva a propiedade e descarta os veciños, así que o segundo enderezo da liña do cliente é o extremo remoto e non outro host nun segmento compartido. Non hai enderezo de hardware, nin tráfico de resolución, nin dominio de difusión ao que unirse, e por iso a interface compórtase como un tubo con exactamente un destino.

Tamén por iso unha ruta dun só host xunto a unha máscara ampla é normal aquí e non un síntoma. A accesibilidade nesta ligazón significa un enderezo, e o núcleo anota exactamente iso. Le os dous enderezos xuntos antes de decidir que a configuración é incorrecta, porque calquera dos dous por si só parece un erro.

Dúas topoloxías, dúas formas de enderezo

A topoloxía punto a punto máis antiga dá a cada cliente un bloque pequeno e usa os dous enderezos centrais, así que a máscara parece un fragmento dunha rede e non un conxunto. A topoloxía de subrede entrega un enderezo do conxunto coa máscara do conxunto e nomea o enderezo de túnel do servidor como o par. Ambas producen unha ligazón válida, e só difiren en que enderezos aparecen no perfil e na máscara que un usuario probablemente cuestionará.

Calquera que sexa a fila que coincida co teu cliente, le primeiro o par, porque nomea o extremo remoto e por tanto explica a máscara. Un perfil copiado entre servidores que usan topoloxías distintas mostrará a forma incorrecta para o seu novo fogar, e esa discrepancia confúndese facilmente cun fallo do servidor.

Cando o conxunto e a rede da oficina reclaman os mesmos bits

Como a ligazón está encamiñada, o conxunto necesita un prefixo que non apareza en ningunha das redes que o servidor pode acadar. Comparte un e o cliente terá unha única ruta para un rango que significa dous lugares, e a ruta instalada máis recentemente decide que lugar gaña. O fallo preséntase no cliente aínda que a decisión que hai detrás pertence ao plan de enderezos. O que informan os usuarios é que o router local desaparece cando se levanta o túnel, ou que só responden algúns hosts da oficina.

Os prefixos que só se parecen son outro caso, e comparar octetos a ollo non é unha comparación de prefixos. Escribe os dous e conta os bits enmascarados: 192.168.4.0/24 contra 192.168.6.0/24 coinciden ata o bit 22 e diverxen no bit 23, porque o terceiro octeto lese 00000100 contra 00000110, así que esas dúas redes son realmente separadas. Pon 10.8.0.0/24 xunto a outra 10.8.0.0/24 e os 24 bits enmascarados coinciden, o que significa que unha ruta non pode expresar ambos lugares. A lonxitude da máscara decide onde se detén a comparación, e a rede instalada en segundo lugar é a que perde.

O que unha ligazón encamiñada non pode entregar

A difusión e o multicast non viaxan por unha ligazón encamiñada, e varias funcións coñecidas constrúense sobre elas. As listas de exploración, os anuncios de nomes e o descubrimento de servizos asumen un segmento compartido, así que un servidor de ficheiros pode responder cada petición por enderezo e aínda así non aparecer nunca nunha lista. A resolución de nomes que depende da difusión local da ligazón falla pola mesma razón, e ningunha edición do perfil cambia o que o túnel pode transportar. Se iso importa é unha cuestión de requisitos, non de encamiñamento.

Un cliente que realmente necesita esas entregas require unha interface ponte, que transporta tramas Ethernet e por tanto conserva o dominio de difusión. O custo é unha ligazón máis ruidosa, a perda do enderezo limpo descrito arriba e unha superficie de fallo moito maior en canto aparecen bucles. Xustifica o requisito antes de cambiar, e prefire un servizo de nomes que funcione sobre ligazóns encamiñadas cando o requisito só trata de nomes.

Ler a interface antes de editar o perfil

Pregunta ao núcleo que instalou, non que parece dicir o perfil. A saída de enderezos mostra o par que explica a máscara, e a saída de rutas mostra se existe un camiño cara a el. Executar ambas contra o dispositivo de túnel leva un momento e resolve a cuestión.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Se eses tres coinciden, o perfil fai o que se configurou para facer, e o problema restante está noutro sitio. Cambia a topoloxía só por un motivo que nomee unha capacidade ausente, porque unha máscara descoñecida non o é.