OpenVPN pada nakon obnove DHCP-a: zadržite rutu do odredišta

Tunel se poveže, zatim ga obnova zakupa na pristupnoj vezi ubije, a dnevnik krivi tajmaut umjesto rute. Ništa u VPN konfiguraciji nije promijenjeno, i to je trag: promijenilo se nešto izvan nje. DHCP događaj je prepisao adresu ili pristupnik, a host ruta koja je držala odredište tunela dostupnim sada pokazuje na sljedeći skok koji više ne postoji. Ovo je problem vlasništva prije nego problem rutiranja.

Uporedite simptom s poludefault rutama

Uz redirect-gateway def1, OpenVPN instalira 0.0.0.0/1 i 128.0.0.0/1 umjesto da zamijeni zadanu rutu. Zajedno te dvije pokrivaju cijeli adresni prostor i pobjeđuju 0.0.0.0/0 samo dužinom prefiksa. Zato svako odredište bez preciznijeg poklapanja ulazi u tunel.

Odredištu treba izuzetak. OpenVPN dodaje host rutu do adrese servera kroz originalni pristupni pristupnik prije nego što poludefault rute uđu, kako bi enkapsulirani paketi mogli izaći. Kada taj izuzetak nestane, ili zadrži sljedeći skok koji više ne postoji, vlastiti vanjski paketi tunela poklope se s poludefault rutom i budu poslani natrag u tunel. Rezultat je veza koja umre pri sljedećem keepaliveu ili rukovanju, a u dnevniku nema ničega što liči na grešku rutiranja.

Potvrdite oblik tablice prije nego što dotaknete bilo šta drugo. ip route show bi trebao prikazati obje polovine plus host rutu za adresu servera; kada host ruta nedostaje, ostatak istrage ima očiglednu početnu točku.

Zašto poludefault rute pobjeđuju bez promjene metrike

Niža metrika ne pobjeđuje duži prefiks. /1 rute pobjeđuju jer kernel prvo poklapa najspecifičniju rutu, pa podizanje metrike na zadanoj ruti ne mijenja ništa u tome kuda ide promet namijenjen tunelu. Jurenje metrika je najčešći pogrešan skretaj u ovoj dijagnozi.

Provjerite odabir s ip route get 203.0.113.10, zamijenivši ga stvarnom adresom servera. Odgovor imenuje sučelje i sljedeći skok koje bi kernel stvarno koristio, što je informativnije od čitanja tablice i rasuđivanja o njoj.

Pokrenite tu naredbu prije nego tunel počne, dok je aktivan i nakon događaja zakupa. Tri odgovora iz jedne naredbe, i tačka razdvajanja postaje vidljiva.

Napravite tri snimke, ne jednu

Prikupite pristupnu adresu, pristupni pristupnik, odredište tunela, odabranu rutu i sva pravila politike u tri trenutka: nakon što je pristupna veza konfigurirana, nakon što se VPN poveže i nakon događaja zakupa ili operatora. Svaka snimka je šačica naredbi, i one imaju smisla samo zajedno. Jedna snimka nakon kvara bilježi stanje, a ne prijelaz. Zapišite naredbe u malu skriptu tako da se svaka snimka uzima na isti način.

Držite snimke u jednoj datoteci s vremenskim oznakama, jer je zanimljivo pitanje kasnije redoslijed. Je li DHCP događaj stigao prije ili nakon što je OpenVPN osvježio svoju rutu? Odgovor odlučuje ko to mora popraviti. Vremenska oznaka s pogrešnog sata gora je od nikakve, pa je uzmite s hosta koji posjeduje tablicu rutiranja.

Kada je odredište konfigurirano kao ime, a ne kao adresa, razriješite ga i u svakoj snimci. DNS promjena na pristupnoj vezi može pomjeriti odredište bez da se ikakva ruta dotakne.

Odlučite koja komponenta osvježava izuzetak

Na dhcpcd sistemu, kuke se pokreću iz direktorija kuka i iz izlazne kuke, a način rada upravitelja razlikuje se po obimu od načina po sučelju. Šta god kuka radi, mora biti idempotentno, jer obnove mogu dolaziti u naletima.

Pouzdan vlasnik je integracija koja već poznaje obje strane: mrežni upravitelj koji upravlja VPN vezom, ili jedinica poredana nakon što se pristupna veza podigne. Statična ruta koju doda kuka radi do sljedeće promjene pristupnika, a zatim padne na potpuno isti način. Ako ipak koristite kuku, natjerajte je da čita trenutni pristupnik u vrijeme izvođenja umjesto da tvrdo kodirate onaj koji ste vidjeli danas.

Zapišite vlasnika unutar konfiguracije. Sljedeća osoba koja bude otklanjala problem ponovnog povezivanja mora znati da je za rutu izuzetka odgovorna kuka, a ne VPN.

Testirajte životni ciklus, ne samo ponovno povezivanje

Prisilite obnovu s dhcpcd -n eth0 ili oslobađanjem i ponovnim uzimanjem zakupa, pa ponovo provjerite ip route get za odredište. Uradite to dvaput, jer drugi prolaz hvata kuke koje dodaju duple rute. Zatim se restartujte, jer je postojanost druga osobina od ispravnosti.

Tunel koji preživi obnovu i restart ima vlasnika i izuzetak koji radi. Onaj koji preživi samo ručni restart nema ni jedno ni drugo, i pasti će pri sljedećem događaju koji ne možete zakazati.