Kaj OpenVPN route-nopull pravzaprav prepreči strežniku pri potiskanju

V odjemalski profil ste vstavili route-nopull, da tunel ne bi pogoltnil vaše privzete poti, zdaj pa je pisarniška podomrežje nedosegljiva, medtem ko odjemalec še vedno pravi, da je povezan. Obe ugotovitvi sta resnični in nič ni spodletelo. Zastavica odjemalcu pove, naj preskoči poti in vnose DHCP, ki jih potiska strežnik, kar je ožje navodilo, kot ga večina pričakuje ob dodajanju. Kar ostane, je delujoč tunel brez mnenja o tem, katere cilje naj uporablja.

Ta vrzel je vsa odločitev, o kateri je ta članek. Bodisi strežnik opisuje omrežje bodisi odjemalec, zastavica pa to delo preda odjemalcu, ne da bi karkoli od tega naredila za vas.

Kaj zastavica izklopi ob povezavi

Odjemalec OpenVPN, ki vleče, običajno po overitvi prevzame od strežnika paket: poti, preusmeritev privzetega prehoda, strežnike DNS in nekaj nastavitvenih direktiv. Ko velja route-nopull, odjemalec še vedno sprejme sejo, še vedno preverja potrdila, še vedno se pogaja o šifrah in keepalive ter še vedno dvigne vmesnik. Kar zavrže, je uporaba potisnjenih vrstic route in potisnjenih vrstic dhcp-option, vključno z DNS.

Zmeda izhaja iz zelene lučke poleg mrtve aplikacije. Tunel obstaja; preslikava ciljev na ta tunel ne. Nič na statusni plošči odjemalca ne loči »povezan in usmerja« od »povezan in nedejaven«, ker sta z vidika tunela oba ista stanja.

Zakaj živ tunel vseeno ne more usmerjati ničesar

Vmesnik se pojavi z lastnim naslovom in na povezavi točka-točka pogosto nima ničesar konkretnejšega od poti do gostitelja proti partnerju. Zasebna podomrežje postane dosegljiva šele, ko neka pot s pravilno predpono kaže na ta vmesnik, z izklopljenim potiskanjem pa ta pot nikoli ne prispe. Preneseni profil običajno tudi ne more pomagati, ker je bil napisan ob predpostavki, da bo strežnik zagotovil natanko te podatke. Zato je vmesnik lahko videti zdrav, medtem ko podomrežje ostane temno.

Branje profila torej dokaže zelo malo. Preberite tekoče stanje na povezanem stroju:

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

Naslov brez poti podomrežja v drugem ukazu je podpis te težave. Tretji ukaz nato odgovori na vprašanje, ki uporabnike res zanima, ker poroča o vmesniku, ki bi ga jedro izbralo za določen cilj, namesto seznama, za katerega ste upali, da ga bo uporabilo. Če odgovori skozi vašo fizično povezavo, tunela sploh ni na poti.

Razreševanje imen spodleti iz povezanega razloga, ne iz ločenega. Potisnjeni vnosi dhcp-option DNS so preskočeni z isto zastavico, zato poizvedbe o notranjih gostiteljih gredo k tistemu razreševalniku, ki ga je zagotovilo lokalno omrežje. Ta razreševalnik nima območja za pisarno, zato poizvedba spodleti ali vrne javni odgovor, in napaka je videti kot težava strežnika, čeprav je težava konfiguracije odjemalca. Preizkušanje naslova pred imenom je tisto, kar loči oboje.

Izbor med zastavico in filtrom predpon

Obe možnosti rešujeta različne oblike iste pritožbe in prav slaba izbira ustvari stanje povezan-a-neuporaben. Ena v celoti nadomesti potisnjeno politiko, druga jo ureja po predponi. Tabela poda kratko različico, odstavek za njo pa pokrije del, ki ljudi preseneti.

pull-filter je ujemalka predpon s tremi glagoli, zato lahko sprejme družino vrstic, jih tiho prezre ali povezavo povsem zavrne, ko se pojavi predpona. Prav zadnje vedenje je vredno poznavanja: pravilo zavrnitve spremeni nesoglasje v politiki v neuspešno rokovanje namesto v tiho izpustitev. Priročnik OpenVPN 2.6 navaja sprejete predpone in natančen pomen vsakega glagola.

Pogosta srednja pot je zavrniti samo redirect-gateway in pustiti pisarniške poti ter DNS, da prispejo po načrtu. To ohranja potiskanje delujoče za dele, ki jih strežnik razume bolje od vas, hkrati pa prepreči tisto eno vrstico, ki bi prevzela vašo privzeto pot.

Ročno dodajanje poti in razreševalnika

Če zastavico obdržite, mora profil povedati, kar bi povedal strežnik. Odjemalske direktive route se uporabijo po vzpostavitvi povezave, zato delujejo ob zastavici, namesto da bi jih ta blokirala. Postavite jih v profil, ne v interaktivno ukazno vrstico, sicer naslednja ponovna povezava ne bo obnovila delujočega stanja.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Vrstica DNS stoji na nerodnem mestu: je odjemalska direktiva, a nekateri odjemalci jo uporabijo le prek integracije DNS platforme, ki jo lahko prepiše, ko se povezava spremeni. Na gostitelju systemd je nastavitev razreševalnika neposredno na vmesniku tunela bolj predvidljiva kot upanje, da bo odjemalec zmagal v tekmovanju prioritet:

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

Domena usmerjanja je enako pomembna kot naslov. Brez nje se lahko poizvedbe o javnih imenih pošljejo tudi notranjemu razreševalniku, in vsak notranji razreševalnik, ki zavrača rekurzijo, bo pokvaril brskanje, medtem ko bo zasebno območje še vedno delovalo. Z njo se k razreševalniku tunela usmerijo le imena pod to pripono, vse ostalo pa sledi fizični povezavi.

Preverjanje rezultata: naslov, ime in zunanja pot

Trije testi ločijo možne okvare. Pridobite zasebni naslov po IP, nato isti gostitelj po imenu, nato običajno javno stran. Delujoč IP z nedelujočim imenom kaže na razreševalnik; nedelujoč IP z delujočim imenom kaže na usmerjanje; če ne delujeta oba, tunela običajno ni na poti.

Nato glejte navzven, ne navznoter. Lastna pot končne točke tunela mora prestati spremembo, vsaka blokirajoča okvara pa mora biti omejena na tunel, ne da bi ujela končno točko. Odjemalec, ki po padcu tunela še naprej brska, je težava politike, ne usmerjanja, in se ne bo pokazal v nobenem od treh testov zgoraj.

Končni seznam zapišite v dokumentacijo profila: poti, razreševalnik, domene in razlog, zakaj vsak obstaja. Ponovna povezava, ki ponovi isto tabelo, je edini dokaz, da je lokalna politika popolna. Če aplikacije še vedno spodletijo z dvignjenim tunelom in vsemi tremi opravljenimi testi, je naslednje mesto za pogled razred težav povezan-a-brezpovezavno, ne pa že preverjena potrdila.