Copiar o /32 do túnel non encamiña a subrede da oficina
O enderezo que a VPN lle dá ao seu adaptador describe a ligazón, non o destino. Engada o prefixo do recurso ao perfil e deixe a ruta predeterminada en paz.
A VPN conéctase, a interface mostra un enderezo cunha máscara de trinta e dous bits e o servidor da oficina segue inalcanzable. O seguinte movemento adoita ser reutilizar esa máscara nunha ruta, coa teoría de que a interface describe o que o túnel pode alcanzar. Non o fai. Ese enderezo describe o extremo local dunha ligazón punto a punto, e o destino que lle importa vive nun prefixo distinto ao outro lado.
Estanse confundindo dúas cousas distintas: o enderezo que lle deu o túnel e a rede á que quere chegar a través del.
Dous enderezos, dúas tarefas
Nun túnel punto a punto, o enderezo do cliente adoita ser un único enderezo de host porque hai exactamente un par no outro extremo da ligazón. Non hai segmento compartido nin ARP, así que unha máscara que parecería absurda en Ethernet aquí é completamente normal.
O prefixo de destino é un feito sobre a rede da oficina, non sobre o túnel. Se necesita un servidor, a ruta é unha ruta de host para ese servidor. Se necesita toda a subrede da oficina, a ruta é a subrede. Ningunha das dúas respostas se pode ler da interface, e escoller unha porque apareceu xunto ao enderezo do túnel é como se rompe unha configuración que funcionaba.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Esa terceira fila é onde o optimismo se converte nunha caída. Encamiñar todo un rango privado cara a un túnel que só serve un sitio empurra tráfico non relacionado cara a un camiño que non o pode entregar, e os fallos resultantes parecen unha VPN rota máis que unha ruta demasiado ampla.
Escolla o prefixo a partir do requisito
Escriba o requisito como unha frase antes de tocar un perfil: que hosts deben ser alcanzables e cal é o prefixo máis estreito que os cobre? Un só servidor é unha ruta de host. Unha subrede é unha ruta de subrede. Un rango de subredes é un resumo, e un resumo é unha promesa de que todo enderezo dentro del é alcanzable, o que raramente é certo.
Despois comprobe o número contra o que a oficina usa en realidade. Copiar un prefixo dunha mensaxe de chat sen confirmalo co plan de direccionamento do sitio é como unha ruta acaba apuntando a unha subrede que ninguén posúe.
Lembre tamén que unha ruta é un camiño, non un permiso. A pasarela segue decidindo se o seu cliente pode usar o destino, e un servizo aínda pode rexeitalo. Instalar a ruta correctamente fai chegar o paquete e non responde nada sobre a autorización.
Engada ao perfil, nunca o substitúa
As rutas dun perfil de NetworkManager son unha propiedade de varios valores, e a diferenza entre establecer e engadir é un carácter. Use a forma con máis para engadir unha entrada e conservar todo o que xa está gardado.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sen o máis, a asignación substitúe toda a lista. Nun perfil que xa leva varios prefixos, iso borra en silencio os que funcionaban, e o síntoma chega máis tarde como un servizo que antes era alcanzable desde este portátil.
Use o UUID en lugar do nome. Os nomes duplícanse tras as restauracións, e a conexión que edita pode non ser a que leva o seu tráfico. Comprobe primeiro se xa existe unha entrada idéntica, porque engadir un duplicado é desordenado mesmo cando é inofensivo.
A referencia de propiedades de ruta documenta o destino, o seguinte salto opcional, a métrica e a sintaxe de atributos para a versión instalada. Léaa antes de engadir un seguinte salto, porque se fai falta depende da integración e da topoloxía, e adiviñalo a partir do primeiro enderezo dunha listaxe de interfaces non é un método.
A ruta predeterminada e o DNS son decisións separadas
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
As rutas automáticas son a outra cousa que non convén perturbar á lixeira. Suprimilas para resolver unha entrada que falta pode eliminar varias que funcionan, e quen o suxeriu normalmente miraba outro perfil con outros push.
O DNS ten o seu propio camiño e os seus propios fallos. Un nome que se resolve ao enderezo correcto a través do resolutor equivocado, ou un resolutor que non pode responder pola zona privada, parecerá un problema de encamiñamento mentres a ruta é perfecta. Probe o enderezo e o nome por separado e logo decida que capa fallou en realidade.
Verifique que se aplicou
Unha modificación gardada non é unha modificación aplicada. Vólvase conectar mediante o ciclo de vida admitido do xestor e despois mire a ruta real para o destino previsto e as regras de política que deciden que táboa se consulta.
Se o prefixo está aí e a conexión segue fallando, pasou a outro problema: selección de enderezo de orixe, unha ruta de retorno no extremo afastado ou un servizo que rexeita o seu cliente. Cada un deses é un lugar mellor onde mirar que o perfil que xa corrixiu.