Avviker importerte VPN-ruter fra den fungerende klienten? Sammenlign begge

En privat tjeneste svarer via VPN mens vanlig internettrafikk oppfører seg helt annerledes enn på maskinen til en kollega, og fristelsen er å konkludere med at Ubuntu-klienten er ødelagt. Den konklusjonen hopper over ett trinn. En fungerende privat operasjon og en avvikende offentlig rute er to observasjoner, og forskjellen ligger vanligvis i trafikkpolitikken hver klient installerte, ikke i klienten selv.

Å sammenligne den lagrede konfigurasjonen med den faktiske nettverkstilstanden tar tre kommandoer og svarer på spørsmålet gjettingen prøvde å svare på.

Lagret profil først, faktisk tilstand deretter

En importert OpenVPN-tilkobling blir sin egen NetworkManager-profil. Filen .ovpn den kom fra slutter å være sannhetens kilde i det importen er ferdig, så å redigere den filen senere endrer ingenting i tilkoblingen du bruker. Dette er det første stedet sammenligningen går galt, og den går galt i stillhet.

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

Les UUID når navnene kolliderer; dupliserte navn overlever reinstallasjoner og profilgjenoppretting, og du kan bruke en time på å redigere kopien som ikke er i bruk. Verdiene du ser beskriver den lagrede hensikten: om profilen kan ta standardruten, hvilke ruter som ble lagret, og hvilke resolvere og søkedomener den ber om. De beskriver ikke hva som skjedde da tilkoblingen ble aktivert, fordi en plugin eller en push fra serveren kan legge til tilstand som profilen ikke nevner. Derfor er neste kommando viktig.

Se deretter på hva systemet faktisk gjorde med den hensikten, inkludert policyregler og hver tabell i stedet for bare hovedtabellen. Lagrede egenskaper er input, og de installerte tabellene er resultatet.

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

To mål, én sammenligning

Velg ett privat mål som fungerer og ett vanlig offentlig mål, og spør kjernen hvilken vei hver av dem ville ta. Å gjøre dette på begge maskinene er det som gjør en vag forskjell til en konkret.

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

Adressene er eksempler som skal byttes ut med dine egne; poenget er paret, ikke tallene. Sammenlign grensesnittet, kildeadressen og tabellen som er navngitt i hver utdata. Når det private oppslaget navngir tunnelen og det offentlige oppslaget også navngir tunnelen, har du en full tunnel, og den andre klienten kan ha en delt, eller omvendt.

Ikke krev at de to klientene skriver ut identisk tekst. En redirect-gateway def1 i OpenVPN uttrykkes vanligvis som to halvprefikseruter i stedet for én standardrute, og en behandler som viser dem annerledes er ikke dermed feil. Vurder dekningen, som oppslagene viser, og ikke formateringen.

Der de to klientene lovlig skiller seg

Klientstandarder er policyvalg og har lov til å være uenige. Ett produkt kan foretrekke en full tunnel, et annet beholder den lokale standarden og ruter bare de private prefiksene, og et tredje følger det serveren sendte. En forskjell er bare en feil når den motsier kravet du fikk.

Sammenlign derfor hver klient mot den godkjente hensikten om delt eller full tunnel, ikke mot hverandre. Hvis kravet er at privat trafikk skal bruke tunnelen og den lokale internettveien forbli lokal, er en full tunnel feilen og en delt tunnel riktig, uansett hvilken klient som gjorde hva. Skriv ned hensikten før du ser på noen av konfigurasjonene, ellers blir den første klienten du undersøker stille standarden.

DNS er en andre akse og svikter uavhengig. En riktig rute kan fortsatt sende spørringer til en resolver som ikke kan svare for den private sonen, og en riktig resolver retter ikke en feil rute. Kontroller begge, og behandle et privat navn som løses opp mens en privat adresse ikke gjør det som bevis på at de to lagene løses separat.

Hold sammenligningen ren

Kjør én tilkoblingseier om gangen. En OpenVPN-økt på kommandolinjen som kjører ved siden av den importerte profilen installerer sine egne ruter og sin egen resolvertilstand, og blandingen som blir resultatet er ingen av klientenes oppførsel. Riv ned den ene før du måler den andre. Start på nytt hvis du er usikker på hva som fortsatt holder tilstand, fordi en gammel rute fra en time siden ser nøyaktig ut som et policyproblem.

Hold alt annet fast også: samme endepunkt, samme konto, samme programvareversjoner, samme nettverk. En suksess på en kollegas Windows-bærbare PC tester en annen klient, en annen resolverintegrasjon og muligens en annen serverprofil, så det er ikke bevis om Ubuntu-behandleren.

NetworkManagers IPv4-innstillingsreferanse definerer never-default og de lagrede ruteegenskapene presist, noe som er verdt å lese før du endrer en administrert verdi. Og husk omfanget av denne sammenligningen: den gjelder IPv4 og sier ingenting om den tilsvarende IPv6-policyen, som har sine egne standardverdier og sin egen måte å overraske deg på.