Skiljer sig importerade VPN-rutter från den fungerande klienten? Jämför båda

Någon privat tjänst svarar via VPN medan vanlig internettrafik beter sig helt annorlunda än på en kollegas maskin, och frestelsen är att dra slutsatsen att Ubuntu-klienten är trasig. Den slutsatsen hoppar över ett steg. En fungerande privat operation och en avvikande publik väg är två observationer, och skillnaden ligger oftast i den trafikpolicy som varje klient installerade, inte i klienten själv.

Att jämföra den sparade konfigurationen med det faktiska nätverkstillståndet tar tre kommandon och besvarar frågan som gissningarna försökte besvara.

Sparad profil först, faktiskt tillstånd sedan

En importerad OpenVPN-anslutning blir en egen NetworkManager-profil. Filen .ovpn som den kom från slutar vara sanningens källa i samma stund som importen är klar, så att redigera den filen senare ändrar ingenting i anslutningen du använder. Det här är första stället där jämförelsen går fel, och den går fel tyst.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Läs UUID när namnen krockar; dubblerade namn överlever ominstallationer och profilåterställningar, och du kan lägga en timme på att redigera kopian som inte används. Värdena du ser beskriver den sparade avsikten: om profilen får ta standardvägen, vilka rutter som sparades och vilka resolvrar och sökdomäner den begär. De beskriver inte vad som hände när anslutningen aktiverades, eftersom ett plugin eller en push från servern kan lägga till tillstånd som profilen inte nämner. Därför spelar nästa kommando roll.

Titta sedan på vad systemet faktiskt gjorde med den avsikten, inklusive policyregler och varje tabell i stället för bara huvudtabellen. Sparade egenskaper är indata, och de installerade tabellerna är resultatet.

ip -4 rule show
ip -4 route show table all

Två destinationer, en jämförelse

Välj en privat destination som fungerar och en vanlig publik destination och fråga kärnan vilken väg var och en skulle ta. Att göra detta på båda maskinerna är det som förvandlar en vag skillnad till en specifik.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

Adresserna är exempel att byta ut mot dina egna; poängen är paret, inte siffrorna. Jämför gränssnittet, källadressen och tabellen som anges i varje utdata. När den privata uppslagningen anger tunneln och den publika uppslagningen också anger tunneln har du en full tunnel och den andra klienten kan ha en delad, eller tvärtom.

Kräv inte att de två klienterna skriver ut identisk text. En redirect-gateway def1 i OpenVPN uttrycks oftast som två halvprefixrutter i stället för en standardrutt, och en hanterare som visar dem annorlunda är inte därmed fel. Bedöm täckningen, som uppslagningarna visar, och inte formateringen.

Där de två klienterna legitimit skiljer sig

Klientstandarder är policysval och får vara oense. En produkt kan föredra en full tunnel, en annan behåller den lokala standarden och dirigerar bara de privata prefixen, och en tredje följer vad servern skickade. En skillnad är bara en defekt när den motsäger kravet du fick.

Jämför därför varje klient mot den godkända avsikten om delad eller full tunnel, inte mot varandra. Om kravet är att privat trafik använder tunneln och den lokala internetvägen förblir lokal, då är en full tunnel buggen och en delad tunnel korrekt, oavsett vilken klient som gjorde vad. Skriv ned avsikten innan du tittar på någon av konfigurationerna, annars blir den första klient du inspekterar tyst standarden.

DNS är en andra axel och den fallerar oberoende. En korrekt rutt kan fortfarande skicka frågor till en resolver som inte kan svara för den privata zonen, och en korrekt resolver fixar inte en felaktig rutt. Kontrollera båda, och behandla ett privat namn som löses upp medan en privat adress inte gör det som bevis för att de två lagren löses separat.

Håll jämförelsen ren

Kör en anslutningsägare i taget. En OpenVPN-session på kommandoraden som körs bredvid den importerade profilen installerar sina egna rutter och sitt eget resolverläge, och blandningen som blir resultatet är ingen av klienternas beteende. Riv ned den ena innan du mäter den andra. Starta om om du är osäker på vad som fortfarande håller tillstånd, för en gammal rutt från en timme sedan ser precis ut som ett policyproblem.

Håll allt annat fast också: samma endpoint, samma konto, samma mjukvaruversioner, samma nätverk. En framgång på en kollegas Windows-bärbara dator testar en annan klient, en annan resolverintegration och möjligen en annan serverprofil, så det är inte bevis om Ubuntu-hanteraren.

NetworkManagers IPv4-inställningsreferens definierar never-default och de sparade rutt-egenskaperna exakt, vilket är värt att läsa innan du ändrar ett hanterat värde. Och kom ihåg omfattningen av denna jämförelse: den gäller IPv4 och säger ingenting om motsvarande IPv6-policy, som har sina egna standardvärden och sitt eget sätt att överraska dig.