Miks kustutatud VPN-marsruut naaseb pärast uuesti ühendamist

Aktiivse marsruudi kustutamine ei muuda midagi, kui profiil, push või alglaadimisüksus loob selle uuesti. Leidke omanik, muutke seda seal ja kontrollige uuesti ühendamisel.

Marsruut, mille te käsitsi kustutasite, on pärast järgmist uuesti ühendamist tagasi ja tabel näeb välja täpselt nagu enne. See ei ole marsruutimise viga: miski loob kirje uuesti konfiguratsioonist või ühenduse elutsükli toimingust. Enamik runbooke peatub aktiivse tabeli juures, mistõttu tundub kustutamine minut aega töötavat ja siis ebaõnnestub. Tuvastage omanik, muutke teda ja tõestage seda uuesti ühendamisel.

Kes marsruudi paigaldas

Alustage kandidaatide loendist, mitte parandusest. VPN-profiil võib kanda oma marsruute, server võib neid ühendamise ajal saata, võrguhalduri profiil võib neid deklareerida, alglaadimisüksus või skript võib neid lisada ja IPsec-implementatsioonid paigaldavad marsruute läbiräägitavate liiklusvalijate jaoks. Poliitikapõhise marsruutimise reeglid võivad samuti suunata liikluse täiesti teise tabelisse.

Ajastus eraldab neid kiiremini kui konfiguratsiooniarheoloogia. Kirje, mis ilmub hetkel, kui liides tõuseb, kuulub kliendile; see, mis saabub sekund hiljem, tuli tavaliselt serveri pushist; see, mis on alglaadimisel olemas, kuulub salvestatud konfiguratsioonile. Registreerige tabel enne ja pärast ühendamist, katkestamist ja taaskäivitust ning muster nimetab omaniku. Marsruut, mis naaseb ainult teenuse taaskäivitamisel, osutab üksusele, mitte VPN-ile.

Lugege tabelit enne selle muutmist

Vaadake kerneli enda vaadet, mitte salvestatud faili. Protokolli veerg näitab, mis iga kirje paigaldas:

ip route show
ip route show table all
ip rule show

Protokolli väli, meetrika ja tabeli number ütlevad teile, kas vaatate staatilist kirjet, kerneli loodud kirjet või midagi, mille deemon lisas. Reeglite loend on oluline, sest otsing võib põhitabelist täielikult lahkuda, mis muudab seal tehtud muudatuse rakendusele nähtamatuks, mida te silute. Lugege rida vasakult paremale: sihtkoht, lüüs, seade, protokoll ja meetrika.

Seejärel küsige kernelilt, millist marsruuti see tegelikult kasutaks. Kaitstud aadress on parem sond kui avalik:

ip route get 10.20.5.7

Muutke omanikku, mitte sümptomit

Kui omanik on teada, kuulub muudatus sellele omanikule. Eemaldage marsruut kliendiprofiilist, parandage saadetud marsruut serveris või muutke võrguhalduri ühendust, selle asemel et lisada konkureeriv püsiv marsruut, mis võidab meetrika järgi. Kaks omavahel võitlevat reeglit tekitavad tabeli, mida keegi hiljem seletada ei suuda.

Säilitage lõpp-punkti erand. Hostimarsruut, mis saadab VPN-serveri enda avaliku aadressi füüsilise lüüsi kaudu, on see, mis hoiab välimised tunnelipaketid voolamas; kustutage see ja tunnel üritab iseennast kanda. Split-tunneli profiilis kehtib sama hool kohalike alamatele, mis peaksid tunnelist mööda minema.

Ühendage uuesti ja kontrollige mõlemat teed

Ühendage uuesti ja seejärel kontrollige mõlemat sihtkohta ühe käiguga. Kaitstud aadress ja erandiga lõpp-punkt vastavad erinevatele küsimustele:

ip route get 10.20.5.7
ip route get 198.51.100.20

Esimene peaks lahenema tunneli liidese kaudu ja teine füüsilise lüüsi kaudu. Kui mõlemad lahenevad tunneli kaudu, on erand puudu; kui kumbki mitte, ei jõustunud profiilimuudatus ja vaatate teist omanikku, kui arvasite.

Kirjutage üles marsruudi eesmärk, selle omanik ja kui kaua see peaks püsima. See märkus on see, mis takistab järgmisel inimesel sama kustutamise ja uuesti ühendamise tsüklit korrata.

Seotud artiklid