Kial forigita VPN-itinero revenas post rekonekto

Itinero, kiun vi forigis mane, revenas post la sekva rekonekto, kaj la tabelo aspektas ekzakte kiel antaŭe. Tio ne estas enkursiga cimo: io rekreas la eron el la agordo aŭ el ago de la vivciklo de la konekto. Plej multaj runbook'oj haltas ĉe la viva tabelo, kaj tial la forigo ŝajnas funkcii dum minuto kaj poste malsukcesas. Identigu la posedanton, ŝanĝu ĝin, kaj pruvu tion ĉe rekonekto.

Kiu instalis la itineron

Komencu per listo de kandidatoj anstataŭ per ripareto. VPN-profilo povas porti proprajn itinerojn, servilo povas puŝi ilin dum konekto, profiloj de retadministrilo povas deklari ilin, starta unuo aŭ skripto povas aldoni ilin, kaj IPsec-realigoj instalas itinerojn por la trafikselektiloj, kiujn ili intertraktas. Reguloj de politika enkursigado ankaŭ povas redirekti trafikon tute al alia tabelo.

Tempo disigas ilin pli rapide ol agada arkeologio. Ero, kiu aperas en la momento, kiam la interfaco ekfunkcias, apartenas al la kliento; unu, kiu alvenas sekundon poste, kutime venis de servila puŝo; unu, kiu ekzistas ĉe starto, apartenas al la konservita agordo. Registru la tabelon antaŭ kaj post konekto, malkonekto kaj restarto, kaj la ŝablono nomos la posedanton. Itinero, kiu revenas nur kiam la servo restartas, montras al unuo anstataŭ al la VPN.

Legu la tabelon antaŭ ol redakti ĝin

Rigardu la propran vidpunkton de la kerno anstataŭ konservitan dosieron. La protokola kolumno montras, kio instalis ĉiun eron:

ip route show
ip route show table all
ip rule show

La protokola kampo, la metriko kaj la tabelnumero diras al vi, ĉu vi rigardas statikan eron, unu kreitan de la kerno aŭ ion aldonitan de demono. La listo de reguloj gravas, ĉar serĉo povas tute forlasi la ĉefan tabelon, kio igas redakton tie nevidebla por la aplikaĵo, kiun vi sencimigas. Legu la linion de maldekstre dekstren: celo, enirejo, aparato, protokolo kaj metriko.

Poste demandu la kernon, kiun itineron ĝi efektive uzus. Protektita adreso estas pli bona sondilo ol publika:

ip route get 10.20.5.7

Ŝanĝu la posedanton, ne la simptomon

Kiam la posedanto estas konata, la ŝanĝo apartenas al tiu posedanto. Forigu la itineron el la klienta profilo, ĝustigu la puŝitan itineron ĉe la servilo, aŭ redaktu la konekton de la retadministrilo anstataŭ aldoni konkurantan daŭran itineron, kiu venkas per la metriko. Du reguloj batalantaj unu kontraŭ la alia produktas tabelon, kiun neniu povos klarigi poste.

Konservu la escepton de la finpunkto. Gastiga itinero, kiu sendas la propran publikan adreson de la VPN-servilo tra la fizika enirejo, estas tio, kio tenas la eksterajn tunelajn pakaĵojn fluantaj; forigu ĝin, kaj la tunelo provas porti sin mem. Ĉe split-tunnel-profilo, la sama zorgo validas por la lokaj subretoj, kiuj devas preterpasi la tunelon.

Rekonektu kaj kontrolu ambaŭ vojojn

Rekonektu, poste kontrolu ambaŭ celojn en unu paŝo. La protektita adreso kaj la esceptita finpunkto respondas al malsamaj demandoj:

ip route get 10.20.5.7
ip route get 198.51.100.20

La unua devus solviĝi tra la tunela interfaco kaj la dua tra la fizika enirejo. Se ambaŭ solviĝas tra la tunelo, la escepto mankas; se neniu, la profila ŝanĝo ne efikiĝis kaj vi rigardas alian posedanton ol vi pensis.

Skribu la celon de la itinero, ĝian posedanton kaj kiom longe ĝi devus vivi. Tiu noto estas tio, kio malhelpas la sekvan personon ripeti la saman ciklon de forigo kaj rekonekto.