Importerede VPN-ruter afviger fra den fungerende klient? Sammenlign begge

Nogle private tjenester svarer gennem VPN, mens almindelig internettrafik opfører sig helt anderledes end på en kollegas maskine, og man friskes til at konkludere, at Ubuntu-klienten er i stykker. Den konklusion springer et skridt over. En fungerende privat operation og en afvigende offentlig vej er to observationer, og forskellen ligger normalt i den trafikpolitik, hver klient installerede, ikke i klienten selv.

At sammenligne den gemte konfiguration med den faktiske netværkstilstand tager tre kommandoer og besvarer det spørgsmål, gætteriet forsøgte at besvare.

Først den gemte profil, derefter den faktiske tilstand

En importeret OpenVPN-forbindelse bliver sin egen NetworkManager-profil. Den .ovpn-fil, den kom fra, holder op med at være sandhedskilde i det øjeblik, importen er færdig, så senere redigering af den fil ændrer intet ved den forbindelse, du bruger. Dette er det første sted, sammenligningen går galt, og den går galt i det stille.

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

Læs UUID'et, når navnene kolliderer; dublerede navne overlever geninstallationer og profilgenskabelser, og du kan bruge en time på at redigere den kopi, der ikke er i brug. De værdier, du ser, beskriver den gemte hensigt: om profilen må tage standardruten, hvilke ruter der blev gemt, og hvilke resolvere og søgedomæner den beder om. De beskriver ikke, hvad der skete, da forbindelsen blev aktiveret, fordi et plugin eller et push fra serveren kan tilføje tilstand, som profilen ikke nævner. Derfor betyder den næste kommando noget.

Se derefter, hvad systemet faktisk gjorde med den hensigt, inklusive politikregler og alle tabeller, ikke kun den primære. Gemte egenskaber er input, og de installerede tabeller er resultatet.

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

To destinationer, én sammenligning

Vælg én privat destination, der virker, og én almindelig offentlig destination, og spørg så kernen, hvilken vej hver af dem ville tage. Det er at gøre dette på begge maskiner, der gør en vag forskel til en konkret.

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

Adresserne er eksempler, du skal erstatte med dine egne; pointen er parret, ikke tallene. Sammenlign interface, kildeaddresse og den tabel, der nævnes i hvert output. Når det private opslag nævner tunnelen, og det offentlige opslag også nævner tunnelen, har du en fuld tunnel, og den anden klient har måske en delt, eller omvendt.

Kræv ikke, at de to klienter udskriver identisk tekst. I OpenVPN udtrykkes redirect-gateway def1 ofte som to halvpræfiksruter i stedet for én standard, og en manager, der viser dem anderledes, er ikke dermed forkert. Vurdér dækningen, som opslagene viser, frem for formateringen.

Hvor de to klienter med rette adskiller sig

Klientstandarder er politiske valg, og de må være uenige. Et produkt kan foretrække en fuld tunnel, et andet kan beholde den lokale standard og kun route de private præfikser, og et tredje kan følge, hvad serveren har pushet. En forskel er kun en fejl, når den modsiger det krav, du har fået.

Sammenlign derfor hver klient med den godkendte hensigt om delt eller fuld tunnel, ikke med hinanden. Hvis kravet er, at privat trafik bruger tunnelen, og den lokale internetvej forbliver lokal, så er en fuld tunnel fejlen, og en delt tunnel er korrekt, uanset hvilken klient der gjorde hvad. Skriv hensigten ned, før du ser på nogen konfiguration, ellers bliver den første klient, du undersøger, i det stille standarden.

DNS er en anden akse og fejler uafhængigt. En korrekt rute kan stadig sende forespørgsler til en resolver, der ikke kan svare for den private zone, og en korrekt resolver retter ikke en forkert rute. Kontrollér begge, og betragt et privat navn, der opløses, mens en privat adresse ikke gør, som bevis for, at de to lag løses separat.

Hold sammenligningen ren

Kør én forbindelsesejer ad gangen. En OpenVPN-session fra kommandolinjen, der kører ved siden af den importerede profil, installerer sine egne ruter og sin egen resolvertilstand, og den resulterende blanding er ingen af klienternes adfærd. Luk den ene ned, før du måler den anden. Genstart, hvis du er usikker på, hvad der stadig holder tilstand, fordi en forældet rute fra en time siden vil se nøjagtigt ud som et politikproblem.

Hold alt andet fast også: samme endepunkt, samme konto, samme softwareversioner, samme netværk. En succes på en kollegas Windows-bærbare tester en anden klient, en anden resolverintegration og muligvis en anden serverprofil, så det er ikke bevis om Ubuntu-manageren.

NetworkManagers reference for IPv4-indstillinger definerer never-default og de gemte ruteegenskaber præcist, hvilket er værd at læse, før du ændrer en administreret værdi. Og husk omfanget af denne sammenligning: den dækker IPv4 og siger intet om den tilsvarende IPv6-politik, som har sine egne standarder og sin egen måde at overraske dig på.