Les rutes VPN importades difereixen del client que funciona? Compareu les dues
Un perfil de NetworkManager desat i les rutes realment instal·lades són dues coses. Compareu destinacions privades i públiques abans de canviar res.
Alguns serveis privats responen a través de la VPN mentre que el trànsit d'internet normal es comporta d'una manera molt diferent de la del maquinari d'un company, i ve la temptació de concloure que el client d'Ubuntu està espatllat. Aquesta conclusió es salta un pas. Una operació privada que funciona i un camí públic diferent són dues observacions, i la diferència sol estar en la política de trànsit que va instal·lar cada client, no en el client mateix.
Comparar la configuració desada amb l'estat real de la xarxa requereix tres ordres i respon la pregunta que les suposicions intentaven respondre.
Primer el perfil desat, després l'estat efectiu
Una connexió OpenVPN importada es converteix en un perfil propi de NetworkManager. El fitxer .ovpn del qual prové deixa de ser la font de veritat en el moment que acaba la importació, així que editar aquell fitxer més tard no canvia res de la connexió que feu servir. Aquest és el primer lloc on la comparació falla, i falla en silenci.
nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn
Llegiu l'UUID quan els noms coincideixin; els noms duplicats sobreviuen a reinstal·lacions i restauracions de perfils, i podeu passar una hora editant la còpia que no s'utilitza. Els valors que veieu descriuen la intenció desada: si el perfil pot agafar la ruta per defecte, quines rutes s'han desat i quins resolutors i dominis de cerca demana. No descriuen què va passar quan es va activar la connexió, perquè un connector o una empenta del servidor poden afegir estat que el perfil no esmenta. Per això importa l'ordre següent.
Després mireu què ha fet realment el sistema amb aquesta intenció, incloent-hi les regles de política i totes les taules, no només la principal. Les propietats desades són entrades, i les taules instal·lades són el resultat.
ip -4 rule show
ip -4 route show table all
Dues destinacions, una comparació
Trieu una destinació privada que funcioni i una destinació pública corrent, i pregunteu al nucli quin camí prendria cadascuna. Fer-ho a les dues màquines és el que converteix una diferència vaga en una de concreta.
ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20
Les adreces són exemples per substituir per les vostres; el que importa és el parell, no els números. Compareu la interfície, l'adreça d'origen i la taula indicada a cada sortida. Quan la consulta privada anomena el túnel i la consulta pública també l'anomena, teniu un túnel complet i l'altre client pot tenir-ne un de dividit, o al revés.
No exigiu que els dos clients imprimeixin un text idèntic. A OpenVPN, redirect-gateway def1 s'expressa sovint com dues rutes de mig prefix en lloc d'una de per defecte, i un gestor que les mostra diferent no és per això incorrecte. Jutgeu la cobertura, que és el que mostren les consultes, no el format.
On els dos clients difereixen legítimament
Els valors per defecte del client són decisions de política, i poden discrepar. Un producte pot preferir un túnel complet, un altre pot mantenir el valor local per defecte i encaminar només els prefixos privats, i un tercer pot seguir el que ha empès el servidor. Una diferència només és un defecte quan contradiu el requisit que us han donat.
Així que compareu cada client amb la intenció aprovada de túnel dividit o complet, no l'un amb l'altre. Si el requisit és que el trànsit privat utilitzi el túnel i el camí d'internet local es quedi local, aleshores un túnel complet és el defecte i un de dividit és correcte, independentment de quin client ha fet què. Escriviu la intenció abans de mirar qualsevol configuració, o el primer client que inspecteu esdevé en silenci el patró.
El DNS és un segon eix i falla de manera independent. Una ruta correcta encara pot enviar consultes a un resolutor que no pot respondre per a la zona privada, i un resolutor correcte no arregla una ruta incorrecta. Comproveu tots dos, i tracteu un nom privat que es resol mentre una adreça privada no ho fa com a prova que les dues capes es resolen per separat.
Manteniu la comparació neta
Executeu un sol propietari de connexió alhora. Una sessió d'OpenVPN per línia d'ordres que corre al costat del perfil importat instal·la les seves rutes i el seu estat de resolutor, i la barreja resultant no és el comportament de cap dels dos clients. Atureu-ne una abans de mesurar l'altra. Reinicieu si no esteu segur de què encara manté estat, perquè una ruta vella d'una hora enrere semblarà exactament un problema de política.
Manteniu també la resta fixa: el mateix punt final, el mateix compte, les mateixes versions de programari, la mateixa xarxa. Un èxit en un portàtil Windows d'un company prova un client diferent, una integració de resolutor diferent i potser un perfil de servidor diferent, així que no és evidència sobre el gestor d'Ubuntu.
La referència de paràmetres IPv4 de NetworkManager defineix amb precisió never-default i les propietats desades de les rutes, cosa que val la pena llegir abans de canviar un valor gestionat. I recordeu l'abast d'aquesta comparació: cobreix IPv4 i no diu res sobre la política IPv6 corresponent, que té els seus propis valors per defecte i la seva pròpia manera de sorprendre-us.