Waarom ’n uitgeveegde VPN-roete ná herverbinding terugkom

’n Roete wat jy met die hand uitgevee het, is ná die volgende herverbinding terug, en die tabel lyk presies soos voorheen. Dit is nie ’n roeteringsfout nie: iets skep die inskrywing weer uit die konfigurasie of uit ’n aksie in die verbindingslewensiklus. Die meeste runbooks stop by die lewende tabel, en daarom lyk dit of die uitvee ’n minuut lank werk en dan misluk dit. Identifiseer die eienaar, verander dit en bewys dit by ’n herverbinding.

Wie die roete geïnstalleer het

Begin met ’n lys kandidate eerder as met ’n regstelling. ’n VPN-profiel kan sy eie roetes dra, ’n bediener kan hulle tydens verbinding stuur, ’n netwerkbestuurder-profiel kan hulle verklaar, ’n boot-eenheid of script kan hulle byvoeg, en IPsec-implementasies installeer roetes vir die verkeerskeuses wat hulle beding. Beleidsroeteringsreëls kan ook verkeer heeltemal na ’n ander tabel herlei.

Tydsberekening skei hulle vinniger as konfigurasie-argeologie. ’n Inskrywing wat verskyn sodra die koppelvlak opkom, behoort aan die kliënt; een wat ’n sekonde later arriveer, kom gewoonlik van ’n bediener-stoot; een wat by die boot bestaan, behoort aan die gestoorde konfigurasie. Teken die tabel aan voor en ná ’n verbinding, ’n ontkoppeling en ’n herbegin, en die patroon noem die eienaar. ’n Roete wat net terugkeer wanneer die diens herbegin, wys op ’n eenheid eerder as op die VPN.

Lees die tabel voordat jy dit wysig

Kyk na die kernel se eie siening eerder as na ’n gestoorde lêer. Die protokol-kolom wys wat elke inskrywing geïnstalleer het:

ip route show
ip route show table all
ip rule show

Die protokolveld, die metrieke waarde en die tabelnommer sê vir jou of jy na ’n statiese inskrywing, een wat die kernel geskep het of iets wat ’n daemon bygevoeg het, kyk. Die reëllisting maak saak, want ’n opsoek kan die hooftabel heeltemal verlaat, wat ’n wysiging daar onsigbaar maak vir die toepassing wat jy ontfout. Lees die reël van links na regs: bestemming, poort, toestel, protokol en metrieke waarde.

Vra dan vir die kernel watter roete hy werklik sou gebruik. ’n Beskermde adres is ’n beter sonde as ’n openbare een:

ip route get 10.20.5.7

Verander die eienaar, nie die simptoom nie

Sodra die eienaar bekend is, hoort die verandering by daardie eienaar. Verwyder die roete uit die kliëntprofiel, korrigeer die gestuurde roete op die bediener, of wysig die netwerkbestuurder-verbinding eerder as om ’n mededingende permanente roete by te voeg wat op metrieke waarde wen. Twee reëls wat teen mekaar veg, lewer ’n tabel op wat niemand later kan verduidelik nie.

Behou die eindpunt-uitsluiting. ’n Gasheerroete wat die VPN-bediener se eie openbare adres deur die fisiese poort stuur, is wat die buitenste tonnelpakette laat vloei; vee dit uit, en die tonnel probeer homself dra. By ’n split-tonnel-profiel geld dieselfde sorg vir die plaaslike subnetwerke wat die tonnel moet omseil.

Herverbind en verifieer beide paadjies

Herverbind en kontroleer dan beide bestemmings in een keer. Die beskermde adres en die uitgeslote eindpunt beantwoord verskillende vrae:

ip route get 10.20.5.7
ip route get 198.51.100.20

Die eerste behoort deur die tonnelkoppelvlak op te los en die tweede deur die fisiese poort. As albei deur die tonnel opgelos word, ontbreek die uitsluiting; as nie een nie, het die profielverandering nie in werking getree nie en kyk jy na ’n ander eienaar as wat jy gedink het.

Skryf die roete se doel, sy eienaar en hoe lank dit moet leef neer. Daardie nota is wat die volgende persoon keer om dieselfde siklus van uitvee en herverbind te herhaal.