Ubuntu har ikkje internett etter at ein VPN-app er fjerna
Ein fjerna VPN-klient kan etterlate NetworkManager-profilar og eit dummy-grensesnitt. Desse foreldrelause objekta held ein standardrute eller ein brannmurregel på plass.
Å avinstallere VPN-klienten, starte på nytt og deretter oppdage at nettlesaren ikkje får lasta noko, er ei vanleg rekkjefølgje på Ubuntu. Tunnelen er borte, men regelen som styrte trafikken dit er ikkje, og på Ubuntu bur desse restane vanlegvis i NetworkManager og ikkje i pakken. Ein tilkoplingsprofil og eit dummy-grensesnitt som blir oppretta under køyring høyrer til ingen pakke, så fjerning av pakken fjernar dei ikkje.
Tunnelen er borte, regelen ikkje
Ein kill switch verkar ved å gjere nettverket ubrukeleg utan tunnelen. Når klienten blir fjerna medan denne tilstanden er aktiv, er det ingenting att som slår han av. Resultatet ser nøyaktig ut som ein øydelagd nettverksadapter og er vanlegvis ein profil som held ei rute.
Derfor gjenopprettar ein ny installasjon nokre gonger tilkoplinga: han gjenopprettar prosessen som veit korleis han skal trekkje tilbake sin eigen regel. Ein klient som vart fjerna medan brytaren var aktiv, etterlet ein tilstand som ingen er att til å rydde opp i.
Les objekta pakken aldri åtte
Les tilstanden før du endrar han. List opp einingar, aktive tilkoplingar og båe rutetabellane, og sjå deretter etter ei dummy-eining som rapporterer at ho er tilkopla, eller ei standardrute som peikar på ei. IPv4 og IPv6 feilar kvar for seg, så ein ping som verkar til ei adresse med øydelagd namneoppslag peikar på eit anna objekt enn ei daud rute. Ei dummy-eining med ei standardrute forklarer heile utfallet åleine.
nmcli device status
nmcli connection show --active
ip -4 route
ip -6 routeSkriv ned det du finn, fordi rettinga er å slette eitt bestemt objekt i staden for å nullstille alt. Noko breiare risikerer eit nytt utfall. Det er skilnaden mellom ein reparasjon og ei gjetting.
Ein tom rutetabell med ei tilkopla eining er ein annan feil, og han peikar på DHCP og ikkje på ein gjenverande profil. Les leigeavtalen før du redigerer noko.
Slett profilen, ikkje nøkkelfila
Slett profilen via NetworkManager i staden for å fjerne nøkkelfila. Sletting av fila lèt profilen i minnet vere aktiv til neste omstart, noko som får ein korrekt reparasjon til å sjå upåliteleg ut. Start deretter tenesta på nytt og les eininglista igjen. Det er omstarten som gjer slettinga verkeleg.
sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManagerViss ei dummy-lenke overlever, fjern den lenka òg, og test deretter ei adresse og eit namn kvar for seg. Rein ruting med eit mislukka namn peikar på DNS, medan ei mislukka adresse peikar på ei rute eller ein brannmur.
Kontroller oppstarts-kroken før han gjentek seg
Nokre restar installerer seg sjølve på nytt ved kvar oppstart. Ein handskriven unit eller eit if-up-skript som legg til brannmurreglar held fram med det etter at pakken er borte, så utfallet kjem tilbake og den tidlegare reparasjonen ser ut som flaks. Søk i unit-filene og nettverkskrokane før du startar på nytt igjen. Unit-namnet er vanlegvis det som avslører det.
systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.dFjern eller masker den bestemte fila, start deretter på nytt éin gong og stadfest at tilstanden utan tunnel er den du vil ha. Den siste omstarten er testen, fordi ei retting som berre held til neste oppstart ikkje er ei retting. Ta vare på notatet saman med maskinen etterpå. nmcli-referansen dekkjer eining- og tilkoplingskommandoane som er brukte ovanfor.