Ko posjeduje adresu, rutu, DNS i firewall na Linux VPN-u?

Dvije skripte koje se bore za istu rutu uobičajen su oblik problema s Linux VPN-om koji se prijavljuje kao greška usmjeravanja. Jedna komponenta stvara tunelski uređaj, druga dodaje zadanu rutu, treća prepisuje konfiguraciju razrješivača, a četvrta ponovno učitava firewall pravila. Bilo koja od njih može poništiti rad druge, a pobjednik je jednostavno ona koja se izvršila posljednja. Pitanje na koje vrijedi odgovoriti nije koji paket instalirati, nego koja je komponenta mjerodavna za svaki dio stanja.

Zapišite tu mapu jednom i većina neuspjeha pri ponovnom povezivanju prestaje biti tajanstvena. Četiri objekta su važna: uređaj i njegove adrese, rute i pravila politike, DNS konfiguracija i firewall.

Uređaj i njegove adrese

Tunelski uređaj stvara ili upravitelj koji poznaje profil ili daemon koji je netko pokrenuo ručno. Oba rasporeda rade sama za sebe; njihovo miješanje ne. Ako NetworkManager posjeduje profil, neka posjeduje i uređaj, i ne pokrećite neupravljani OpenVPN-proces protiv istog imena tunela.

Zabilježite ko uklanja uređaj kad sesija završi. Uređaj koji nadživi svoju sesiju najčešći je izvor zastarjelih adresa i zbrke koja slijedi.

Rute i pravila politike

Upravo na rutama sukobi vlasništva čine vidljivu štetu. Upravitelj veze instalira zadanu rutu za tunel plus specifičniju rutu za udaljenu mrežu; rukom napisana skripta zatim dodaje svoju zadanu rutu s drugom metrikom i tiho pobjeđuje ili gubi ovisno o vremenu. Odlučite koji su unosi vezani uz vezu, koji su trajna politika i koja komponenta ih osvježava nakon ponovnog povezivanja. Zatim držite ostale komponente izvan te tablice.

Pravila politike zaslužuju istu jasnoću, jer pravilo koje pokazuje na tablicu koju nitko ne popunjava stvara crnu rupu koja izgleda točno kao mrtav tunel. Ako pravilo postoji da bi prisililo promet negdje, tablicu koju odabire mora održavati isti vlasnik.

DNS je uvijek zaseban vlasnik

Daemon razrješivača radi kao vlastiti proces pod vlastitim identitetom, pa ne nasljeđuje slučajno odluke usmjeravanja tunela. Kad VPN gura DNS poslužitelje, nešto to mora prevesti u konfiguraciju po vezi koju razrješivač poštuje, i nešto je mora poslije ukloniti.

Mit je ovdje da pisanje poslužitelja imena u profil mijenja kamo idu upiti. Mijenja što se govori razrješivaču, ne koji socket razrješivač koristi prema van. Testirajte upitom plus provjerom rute umjesto da vjerujete datoteci.

Stanje firewalla i ko ga obnavlja

Firewall pravila najčešće se prebrisavaju na VPN hostu. Upravitelj može dodavati NAT ili pravila prosljeđivanja po vezi, dok servis firewalla pri podizanju ponovno učitava spremljeni skup pravila i briše ih. Odaberite jedan autoritet za politiku i učinite drugi njegovim potrošačem, ili prihvatite da ponovno pokretanje tiho mijenja ponašanje. Iznimke vezane uz vezu pripadaju u datoteku koju učitava isti vlasnik, a ne u iptables naredbu otipkanu tijekom rješavanja problema.

Ako pravila moraju preživjeti ponovno povezivanje, recite to izričito. Ako ne moraju, recite i to, jer sljedeći će inženjer pretpostaviti odgovor koji mu je prikladniji.

Životni ciklus: podizanje, ponovno povezivanje, rasklapanje

Dajte svakom od ta tri trenutka vlasnika. Pri podizanju odlučite što priprema preduvjete i kojim redom. Pri mekom ponovnom pokretanju zapamtite da uređaj može preživjeti dok stanje sesije ne može, pa mora raditi validator, a ne stvaratelj. Pri rasklapanju uklonite samo ono što je ova veza stvorila, jer resetiranje svake rute ili brisanje cijelog firewalla nije isto kao umirovljenje jednog tunela.

Za promatranje, ip monitor link address route prikazuje promjene jezgre kako se događaju, ali izvješćuje o događajima, a ne o namjeri: izbrisana ruta ne govori ništa o tome koja ju je proces izbrisao. Uparite ga s mapom vlasništva i zbunjujuće zaustavljanje postaje kratak popis kandidata.

Iznimke također imaju cijenu. Označavanje cijele klase uređaja kao neupravljane da bi se pobjeglo od sukoba predaje to stanje nikome, što je odluka, a ne popravak.