Šta OpenVPN-ov route-nopull zapravo zaustavlja da server gura

Stavili ste route-nopull u profil klijenta da tunel ne bi progutao vašu zadanu rutu, a sada je podmreža ureda nedostupna dok klijent i dalje tvrdi da je povezan. Oba zapažanja su tačna i ništa nije otkazalo. Zastavica govori klijentu da preskoči rute i DHCP unose koje server gura, što je uža instrukcija nego što većina ljudi očekuje kada je doda. Ono što ostaje je radni tunel bez mišljenja o tome koja odredišta ga trebaju koristiti.

Ta praznina je cijela odluka o kojoj govori ovaj članak. Ili server opisuje mrežu, ili to čini klijent, a zastavica predaje taj posao klijentu ne radeći ništa od toga za vas.

Šta zastavica isključuje u trenutku povezivanja

Klijent OpenVPN koji povlači obično nakon autentifikacije preuzme paket od servera: rute, preusmjeravanje zadanog pristupa, DNS servere i nekoliko direktiva za podešavanje. Kada je route-nopull na snazi, klijent i dalje prihvata sesiju, i dalje provjerava certifikate, i dalje pregovara šifre i keepalive i i dalje podiže interfejs. Ono što odbacuje je primjena gurnutih route redova i gurnutih dhcp-option redova, uključujući DNS.

Zabuna dolazi od zelenog indikatora pored mrtve aplikacije. Tunel postoji; mapiranje odredišta na taj tunel ne postoji. Ništa na statusnoj ploči klijenta ne razlikuje „povezan i usmjerava“ od „povezan i inertan“, jer su iz ugla tunela oba ista stanja.

Zašto živ tunel ipak može ne usmjeravati ništa

Interfejs se pojavljuje sa svojom adresom i, na vezi od tačke do tačke, često ništa konkretnije od rute domaćina prema partneru. Privatna podmreža postaje dostupna samo kada neka ruta pokazuje na taj interfejs s ispravnim prefiksom, a kada je guranje onemogućeno, ta ruta nikada ne stiže. Preuzeti profil takođe obično ne može pomoći, jer je napisan uz pretpostavku da će server dati upravo te informacije. Zato interfejs može izgledati zdrav dok podmreža ostaje mračna.

Čitanje profila zato dokazuje vrlo malo. Čitajte pokrenuto stanje, na povezanoj mašini:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Adresa bez rute podmreže u drugoj naredbi potpis je ovog problema. Treća naredba zatim odgovara na pitanje koje korisnike zaista zanima, jer izvještava koji bi interfejs jezgro izabralo za određeno odredište, a ne spisak za koji ste se nadali da će se koristiti. Ako odgovori preko vaše fizičke veze, tunela uopšte nema na putu.

Razrješavanje imena pada zbog povezanog, a ne zasebnog razloga. Gurnuti unosi dhcp-option DNS preskaču se istom zastavicom, pa upiti za interne domaćine idu onom razrješivaču koji je dala lokalna mreža. Taj razrješivač nema zonu za ured, pa upit pada ili vraća javni odgovor, a kvar izgleda kao problem servera dok je problem konfiguracije klijenta. Testiranje adrese prije imena je ono što razdvaja to dvoje.

Biranje između zastavice i filtra prefiksa

Dvije opcije rješavaju različite oblike iste pritužbe, a loš izbor stvara stanje „povezano, ali beskorisno“. Jedna zamjenjuje gurnutu politiku u cjelini, dok je druga uređuje po prefiksu. Tabela daje kratku verziju, a pasus nakon nje pokriva dio koji ljude iznenadi.

pull-filter je uparivač prefiksa s tri glagola, pa može prihvatiti porodicu redova, tiho ih ignorisati ili odbiti vezu potpuno kada se prefiks pojavi. To posljednje ponašanje je ono koje vrijedi znati: pravilo odbijanja pretvara neslaganje u politici u neuspjelo rukovanje umjesto tihog izostavljanja. Priručnik OpenVPN 2.6 navodi prihvaćene prefikse i tačnu semantiku svakog glagola.

Čest srednji put je odbiti samo redirect-gateway i pustiti uredske rute i DNS da stignu kako je predviđeno. To održava guranje radnim za dijelove koje server razumije bolje od vas, dok sprječava onaj jedan red koji bi preuzeo vašu zadanu rutu.

Ručno dodavanje ruta i razrješivača

Ako zadržite zastavicu, profil mora reći ono što bi server rekao. Klijentske direktive route primjenjuju se nakon uspostavljanja veze, pa rade uz zastavicu umjesto da ih ona blokira. Stavite ih u profil, ne u interaktivnu komandnu liniju, inače sljedeće ponovno povezivanje neće reproducirati radno stanje.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS red stoji u nezgodnom položaju: to je klijentska direktiva, ali neki klijenti je primjenjuju samo kroz DNS integraciju platforme, koja je može prepisati kada se veza promijeni. Na systemd domaćinu, postavljanje razrješivača direktno na interfejs tunela predvidljivije je od nade da će klijent pobijediti u takmičenju prioriteta:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Domen usmjeravanja važan je koliko i adresa. Bez njega se upiti za javna imena takođe mogu slati internom razrješivaču, a svaki interni razrješivač koji odbija rekurziju slomit će pregledanje dok privatna zona ostaje radna. S njim se samo imena pod tim sufiksom usmjeravaju na razrješivač tunela, a sve ostalo slijedi fizičku vezu.

Provjera rezultata: adresa, ime i vanjski put

Tri testa razdvajaju moguće kvarove. Dohvatite privatnu adresu po IP-u, zatim isti domaćin po imenu, zatim običan javni sajt. Radni IP s neuspjelim imenom ukazuje na razrješivač; neuspjeli IP s radnim imenom ukazuje na usmjeravanje; oba neuspjela obično znače da tunel nije na putu.

Zatim gledajte prema van, a ne prema unutra. Vlastita ruta krajnje točke tunela mora preživjeti promjenu, a svako blokiranje kvara mora biti ograničeno na tunel bez hvatanja krajnje točke. Klijent koji nastavi pregledati nakon pada tunela je problem politike, ne usmjeravanja, i neće se pojaviti ni u jednom od tri testa gore.

Upišite konačni spisak u dokumentaciju profila: rute, razrješivač, domene i razlog postojanja svakog. Ponovno povezivanje koje reprodukuje istu tabelu jedini je dokaz da je lokalna politika potpuna. Ako aplikacije i dalje ne rade dok je tunel podignut i sva tri testa prolaze, sljedeće mjesto za pogledati je klasa problema „povezano, ali offline“, a ne certifikati koji su već provjereni.