Ko treba da posjeduje rute i DNS kada se openfortivpn povezuje?

Četiri faze se naslanjaju jedna na drugu u radnoj openfortivpn sesiji. Klijent se autentificira na gatewayu i pokreće TLS vezu, zatim unutar te veze pokreće PPP, potom prima adresu i DNS informacije, i na kraju primjenjuje rute hosta i postavke resolvera. Svaka faza može biti živa dok sljedeća nije, i zato je “povezano” tako klizava riječ u temama podrške.

Odluka koja uklanja većinu zabune je ko posjeduje posljednju fazu. Ili VPN klijent sam primjenjuje promjene hosta, ili to radi druga komponenta, a miješanje to dvoje na pola puta je način na koji rute i datoteke resolvera završe opisujući različite sesije.

Četiri faze koje izgledaju kao jedna veza

Prva faza je prijem. imenovana domena za autentifikaciju ili jednokratni kod, i prima parametre potrebne za nastavak. Kada klijent ispiše da je povezan na gateway, to znači da TLS transport radi. To ne znači da je PPP pregovarao, i sigurno ne znači da je interna aplikacija dostupna.

Druga faza je PPP veza. Klijent pokreće PPP proces prema tunel uređaju, a dvije strane pregovaraju opcije veze i adrese. Tek nakon toga host zna koje lokalne i udaljene adrese sesija koristi, i tek tada ruta koja pokazuje u tunel ima smisla.

Treća faza je primjena tih informacija na host, i tu je vlasništvo važno. Klijent može dodati rute i prepisati konfiguraciju resolvera, ili mu se može reći da se povuče i oboje prepusti onome što inače upravlja mrežom na tom računaru. Projektni README to opisuje kao odvojene odgovornosti, a ne kao jedno automatsko ponašanje.

Ko uređuje tablicu rutiranja

Po defaultu klijent je vlasnik. Dodaje rutu prema gatewayu kroz fizičko sučelje, rutu za peer tunela i rute za mreže koje sesija smije koristiti, a zatim ih uklanja kada proces izađe. Taj default je zgodan na laptopu s jednim mrežnim menadžerom i bez drugog VPN softvera.

Odaberite predaju samo kada nešto drugo stvarno posjeduje rutiranje. Integracija mrežnog menadžera, mrežni namespace kontejnera ili agent za rutiranje na razini cijelog lokaliteta možda već zna kako instalirati i očistiti iste prefikse. Prosljeđivanje opcije no-routes tada sprječava dva pisca da se tuku oko iste tablice, a to je utrka koja se pokazuje kao povremeni gubitak jedne podmreže, a ne kao čist kvar.

Preklapanje je drugi razlog za predaju. Ako gurane rute uključuju prefiks koji lokalna mreža već koristi, klijent ne može riješiti sukob umjesto vas. Neko mora odlučiti je li taj prefiks dostupan kroz tunel, kroz fizičku vezu ili kroz specifičniju rutu, a ta odluka pripada onome ko posjeduje topologiju.

Čišćenje je treće. Klijent koji padne prije uklanjanja svojih ruta ostavlja crnu rupu koja nadživi sesiju, a sljedeća veza može dodati duplikat povrh nje. Ko posjeduje rutiranje, posjeduje i provjeru da su stari unosi nestali. Učinite tu provjeru dijelom putanje podizanja, a ne opcionalnim korakom čišćenja.

Ko posjeduje DNS i datoteku resolvera

DNS je ista odluka s oštrijim rubovima. Klijent može prihvatiti DNS servere koje prijavi gateway ili PPP peer i upisati ih u konfiguraciju resolvera hosta. Na jednostavnom računaru to je upravo ono što želite, jer se interna imena tada razrješavaju samo dok je tunel aktivan.

Na modernom Linux hostu resolverom može upravljati lokalni stub, a prepisivanje datoteke resolvera iza leđa tog stuba proizvodi konfiguraciju koja izgleda ispravno i ponaša se nedosljedno. Ako host već pokreće menadžer resolvera, pustite ga da posjeduje DNS i hranite ga serverima tunela kroz njegovo podržano sučelje. Klijentova opcija no-dns je tamo ispravan izbor, a ne zaobilazno rješenje.

Split DNS je odvojeno pitanje od toga ko piše datoteku. Slanje svakog upita kroz tunel je jednostavno i sporo; slanje samo internih zona kroz njega zahtijeva konfiguraciju po domeni koju većina jednostavnih klijenata ne nudi. Odlučite koje ponašanje host treba prije nego što omogućite promjene resolvera u klijentu. Pogrešan izbor ovdje izgleda kao ispad razrješavanja imena čak i kada je sam tunel u redu.

Privilegije, spremnost i predaja

Stvaranje tunel uređaja i uređivanje ruta hosta ili stanja resolvera zahtijeva povišene mrežne ovlasti. Uobičajena greška je zaključiti da sve zato mora raditi kao root, uključujući pretraživač ili aplikaciju koja koristi tunel. Držite privilegirani dio malim: klijent i njegova konfiguracijska datoteka, u vlasništvu administratora, dok korisničke aplikacije zadržavaju svoj normalni račun.

Spremnost treba definirati po potrošaču. Nadzornik može smatrati uslugu pokrenutom kada klijentski proces radi i tunel uređaj postoji. Posao sigurnosne kopije treba smatrati VPN upotrebljivim samo kada njegova storage krajnja točka odgovara kroz tunel. To su različite provjere, a korištenje slabije za jaču svrhu proizvodi poslove koji počinju prerano i povremeno padaju. Zapišite odabranu definiciju, jer nadzornik i posao koji se ne slažu oko spremnosti su tiket za podršku koji čeka da se dogodi.

Testirajte ugovor s četiri opažanja: faza gatewaya završava, PPP dodjeljuje adrese, predviđena ruta je prisutna i zahtjev prema internom hostu uspijeva. Zatim zaustavite klijenta i potvrdite da je svako od toga uklonjeno ili vraćeno. Ako host još uvijek razrješava interna imena ili još uvijek drži rutu nakon zatvaranja tunela, predaja vlasništva nije potpuna.