Hvorfor en slettet VPN-rute vender tilbage efter genopkobling

En rute, du slettede manuelt, er tilbage efter den næste genopkobling, og tabellen ser præcis ud som før. Det er ikke en routingfejl: noget genskaber posten ud fra konfigurationen eller fra en handling i forbindelsens livscyklus. De fleste runbooks stopper ved den aktive tabel, og derfor ser sletningen ud til at virke et minut og fejler derefter. Find ejeren, ændr den, og bevis det ved en genopkobling.

Hvem installerede ruten

Start med en liste over kandidater i stedet for en rettelse. En VPN-profil kan bære sine egne ruter, en server kan sende dem ved forbindelse, en netværksadministratorprofil kan erklære dem, en boot-enhed eller et script kan tilføje dem, og IPsec-implementeringer installerer ruter for de trafikvælgere, de forhandler. Policy-routingregler kan også omdirigere trafik helt til en anden tabel.

Timing adskiller dem hurtigere end konfigurationsarkæologi. En post, der vises i det øjeblik, grænsefladen kommer op, tilhører klienten; en, der ankommer et sekund senere, kom normalt fra et server-push; en, der findes ved boot, tilhører den gemte konfiguration. Registrér tabellen før og efter en forbindelse, en afbrydelse og en genstart, og mønsteret navngiver ejeren. En rute, der kun vender tilbage, når tjenesten genstarter, peger på en enhed frem for på VPN’en.

Læs tabellen, før du redigerer den

Se kernelens eget syn i stedet for en gemt fil. Protokol-kolonnen viser, hvad der installerede hver post:

ip route show
ip route show table all
ip rule show

Protokolfeltet, metrikken og tabelnummeret fortæller dig, om du ser på en statisk post, en kernel-oprettet post eller noget, en dæmon har tilføjet. Regeloversigten er vigtig, fordi et opslag helt kan forlade hovedtabellen, hvilket gør en ændring der usynlig for det program, du fejlretter. Læs linjen fra venstre mod højre: destination, gateway, enhed, protokol og metrik.

Spørg derefter kernen, hvilken rute den faktisk ville bruge. En beskyttet adresse er en bedre sonde end en offentlig:

ip route get 10.20.5.7

Ændr ejeren, ikke symptomet

Når ejeren er kendt, hører ændringen til hos den ejer. Fjern ruten fra klientprofilen, ret den pushede rute på serveren, eller rediger netværksadministratorforbindelsen i stedet for at tilføje en konkurrerende permanent rute, der vinder på metrik. To regler, der kæmper mod hinanden, giver en tabel, som ingen senere kan forklare.

Behold undtagelsen for endepunktet. En værtsrute, der sender VPN-serverens egen offentlige adresse gennem den fysiske gateway, er det, der holder de ydre tunnelpakker i gang; slet den, og tunnelen forsøger at bære sig selv. På en split-tunnel-profil gælder samme omhu for de lokale undernet, der skal omgå tunnelen.

Genopkobl og verificér begge veje

Genopkobl, og kontrollér derefter begge destinationer i én gennemgang. Den beskyttede adresse og det undtagne endepunkt besvarer forskellige spørgsmål:

ip route get 10.20.5.7
ip route get 198.51.100.20

Den første bør opløses gennem tunnelgrænsefladen og den anden gennem den fysiske gateway. Hvis begge opløses gennem tunnelen, mangler undtagelsen; hvis ingen gør, har profilændringen ikke fået effekt, og du ser på en anden ejer, end du troede.

Skriv rutens formål, dens ejer og hvor længe den skal leve ned. Den note er det, der forhindrer den næste person i at gentage den samme slette-og-genopkobl-cyklus.