Skil importerte VPN-ruter seg frå den fungerande klienten? Samanlikn begge
Ein lagra NetworkManager-profil og rutene som faktisk er installerte er to ulike ting. Samanlikn private og offentlege mål før du endrar noko.
Ein privat teneste svarar via VPN medan vanleg internettrafikk oppfører seg heilt annleis enn på maskina til ein kollega, og freistinga er å konkludere med at Ubuntu-klienten er øydelagd. Den konklusjonen hoppar over eitt steg. Ein fungerande privat operasjon og ei avvikande offentleg rute er to observasjonar, og skilnaden ligg vanlegvis i trafikkpolitikken kvar klient installerte, ikkje i klienten sjølv.
Å samanlikne den lagra konfigurasjonen med den faktiske nettverkstilstanden tek tre kommandoar og svarar på spørsmålet gjettinga prøvde å svare på.
Lagra profil først, faktisk tilstand deretter
Ei importert OpenVPN-tilkopling blir sin eigen NetworkManager-profil. Fila .ovpn ho kom frå sluttar å vere sanningas kjelde i det importen er ferdig, så å redigere den fila seinare endrar ingenting i tilkoplinga du brukar. Dette er det første staden samanlikninga går gale, og ho går gale i stillheit.
nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn
Les UUID når namna kolliderer; dupliserte namn overlever reinstallasjonar og profilgjenoppretting, og du kan bruke ein time på å redigere kopien som ikkje er i bruk. Verdiane du ser skildrar den lagra hensikta: om profilen kan ta standardruta, kva ruter som vart lagra, og kva resolvarar og søkedomene han ber om. Dei skildrar ikkje kva som skjedde då tilkoplinga vart aktivert, fordi ein plugin eller ein push frå serveren kan leggje til tilstand som profilen ikkje nemner. Difor er neste kommando viktig.
Sjå deretter på kva systemet faktisk gjorde med den hensikta, inkludert policyreglar og kvar tabell i staden for berre hovudtabellen. Lagra eigenskapar er input, og dei installerte tabellane er resultatet.
ip -4 rule show
ip -4 route show table all
To mål, éi samanlikning
Vel eitt privat mål som fungerer og eitt vanleg offentleg mål, og spør kjernen kva veg kvar av dei ville ta. Å gjere dette på begge maskinene er det som gjer ein vag skilnad til ein konkret.
ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20
Adressene er døme som skal bytast ut med dine eigne; poenget er paret, ikkje tala. Samanlikn grensesnittet, kildeadressa og tabellen som er namngitt i kvar utdata. Når det private oppslaget nemner tunnelen og det offentlege oppslaget òg nemner tunnelen, har du ein full tunnel, og den andre klienten kan ha ein delt, eller omvendt.
Krev ikkje at dei to klientane skriv ut identisk tekst. Ein redirect-gateway def1 i OpenVPN vert vanlegvis uttrykt som to halvprefiksruter i staden for éi standardrute, og ein behandlar som viser dei annleis er ikkje dermed feil. Vurder dekninga, som oppslaga viser, og ikkje formateringa.
Der dei to klientane lovleg skil seg
Klientstandardar er policyval og har lov til å vere ueinige. Eitt produkt kan føretrekkje ein full tunnel, eit anna held den lokale standarden og ruter berre dei private prefiksa, og eit tredje følgjer det serveren sende. Ein skilnad er berre ein feil når han motseier kravet du fekk.
Samanlikn difor kvar klient mot den godkjende hensikta om delt eller full tunnel, ikkje mot kvarandre. Viss kravet er at privat trafikk skal bruke tunnelen og den lokale internettvegen halde seg lokal, er ein full tunnel feilen og ein delt tunnel riktig, uansett kva klient som gjorde kva. Skriv ned hensikta før du ser på nokon av konfigurasjonane, elles blir den første klienten du undersøkjer stille standarden.
DNS er ein andre akse og sviktar uavhengig. Ei riktig rute kan framleis sende spørjingar til ein resolvar som ikkje kan svare for den private sona, og ein riktig resolvar rettar ikkje ei feil rute. Kontroller begge, og handsam eit privat namn som blir løyst opp medan ei privat adresse ikkje blir det som prov på at dei to laga blir løyste kvar for seg.
Hald samanlikninga rein
Køyr éin tilkoplingseigar om gongen. Ei OpenVPN-økt på kommandolinja som køyrer ved sida av den importerte profilen installerar sine eigne ruter og sin eigen resolvartilstand, og blandinga som blir resultatet er inga av klientane si åtferd. Riv ned den eine før du måler den andre. Start på nytt viss du er usikker på kva som framleis held tilstand, fordi ei gammal rute frå ein time sidan ser nøyaktig ut som eit policyproblem.
Hald alt anna fast òg: same endepunkt, same konto, same programvareversjonar, same nettverk. Ein suksess på den Windows-berbare PC-en til ein kollega testar ein annan klient, ein annan resolvarintegrasjon og moglegvis ein annan serverprofil, så det er ikkje prov om Ubuntu-behandlaren.
NetworkManagers IPv4-innstillingsreferanse definerer never-default og dei lagra ruteeigenskapane presist, noko som er verdt å lese før du endrar ein administrert verdi. Og hugs omfanget av denne samanlikninga: ho gjeld IPv4 og seier ingenting om den tilsvarande IPv6-politikken, som har sine eigne standardverdiar og sin eigen måte å overraske deg på.