Dve skripti, ki se borita za isto pot, sta običajna oblika težave z Linux VPN, ki se zabeleži kot napaka usmerjanja. Ena komponenta ustvari tunelsko napravo, druga doda privzeto pot, tretja prepiše konfiguracijo razreševalnika, četrta pa znova naloži pravila požarnega zidu. Vsaka od njih lahko razveljavi delo druge, in zmagovalec je preprosto tisti, ki je tekel zadnji. Vprašanje, na katero se je vredno odzvati, ni, kateri paket namestiti, ampak katera komponenta je pristojna za vsak del stanja.

Zapišite ta zemljevid enkrat in večina neuspehov ponovne povezave preneha biti skrivnostna. Pomembni so štirje objekti: naprava in njeni naslovi, poti in pravila politike, konfiguracija DNS in požarni zid.

Naprava in njeni naslovi

Tunelsko napravo ustvari bodisi upravitelj, ki pozna profil, bodisi demon, ki ga je nekdo zagnal ročno. Obe ureditvi delujeta sami zase; njunega mešanja ne. Če ima profil v lasti NetworkManager, naj ima tudi napravo, in ne zaženite neupravljane OpenVPN procesa proti istemu imenu tunela.

Zabeležite, kdo odstrani napravo, ko se seja konča. Naprava, ki preživi svojo sejo, je najpogostejši vir zastarelih naslovov in zmede, ki jim sledi.

Poti in pravila politike

Prav na poteh konflikti lastništva povzročajo vidno škodo. Upravitelj povezave namesti privzeto pot za tunel in natančnejšo pot za oddaljeno omrežje; ročno napisana skripta nato doda svojo privzeto pot z drugo metriko in tiho zmaga ali izgubi glede na čas. Odločite, kateri vnosi so vezani na povezavo, kateri so trajna politika in katera komponenta jih po ponovni povezavi osveži. Nato držite druge komponente izven te tabele.

Pravila politike si zaslužijo enako jasnost, ker pravilo, ki kaže na tabelo, ki je nihče ne izpolni, ustvari črno luknjo, ki je videti natanko kot mrtv tunel. Če pravilo obstaja zato, da promet nekam potisne, mora tabelo, ki jo izbere, vzdrževati isti lastnik.

DNS je vedno ločen lastnik

Demon razreševalnika teče kot svoj proces pod svojo identiteto, zato ne podeduje odločitev usmerjanja tunela po nesreči. Ko VPN potiska strežnike DNS, mora nekaj to prevesti v konfiguracijo za vsako povezavo, ki jo razreševalnik spoštuje, in nekaj jo mora nato odstraniti.

Mit tukaj je, da pisanje strežnika imen v profil spremeni, kam gredo poizvedbe. Spremeni, kaj se pove razreševalniku, ne katero vtičnico razreševalnik uporablja navzgor. Preizkusite s poizvedbo in iskanjem poti namesto zaupanja datoteki.

Stanje požarnega zidu in kdo ga obnovi

Pravila požarnega zidu so najpogosteje prepisani objekt na gostitelju VPN. Upravitelj lahko doda pravila NAT ali posredovanja za vsako povezavo, medtem ko storitev požarnega zidu ob zagonu znova naloži shranjen nabor pravil in jih izbriše. Izberite eno oblast za politiko in drugo naredite za njeno porabnico, ali sprejmite, da ponovni zagon tiho spremeni vedenje. Izjeme, vezane na povezavo, sodijo v datoteko, ki jo naloži isti lastnik, ne v ukaz iptables, vtipkan med odpravljanjem težav.

Če morajo pravila preživeti ponovno povezavo, to povejte izrecno. Če ne, povejte tudi to, ker bo naslednji inženir predpostavil priročnejši odgovor.

Življenjski cikel: zagon, ponovna povezava, razstavljanje

Vsakemu od teh treh trenutkov dajte lastnika. Ob zagonu odločite, kaj pripravi predpogoje in v kakšnem vrstnem redu. Ob mehkem ponovnem zagonu si zapomnite, da lahko naprava preživi, stanje seje pa ne, zato mora teči preverjevalnik, ne ustvarjalec. Ob razstavljanju odstranite samo to, kar je ustvarila ta povezava, ker ponastavitev vsake poti ali praznjenje celotnega požarnega zidu ni isto kot umik enega tunela iz uporabe.

Za opazovanje ip monitor link address route prikazuje spremembe jedra, ko se zgodijo, vendar poroča o dogodkih, ne o nameri: izbrisana pot ne pove ničesar o tem, kateri proces jo je izbrisal. Povežite ga z zemljevidom lastništva in zmeden izklop postane kratek seznam kandidatov.

Tudi izjeme imajo ceno. Označitev celotnega razreda naprav kot neupravljanega, da bi se izognili konfliktu, to stanje prepusti nikomur, kar je odločitev, ne popravek.

Sorodni članki