pull-filter v OpenVPN se ujema z več kot samo zamišljeno potjo

Dodate eno vrstico, da obdržite lokalno privzeto pot, in nato tunel ne doseže več notranjega strežnika DNS. Vrstica je bila pull-filter ignore "route", kar ne pomeni »ne upoštevaj te poti«. Pomeni »zavrzi vsako potisnjeno možnost, katere besedilo se začne s temi petimi črkami«, na običajnem strežniku pa to vključuje route-gateway, route-metric in route-ipv6 skupaj s samimi potmi. Spodnji kontrolni seznam je tisto, kar preidem, preden se dotaknem profila, ki ga mora uporabljati nekdo drug.

Filter deluje samo na potisnjene možnosti

pull-filter deluje samo na vrstice možnosti, ki jih strežnik pošlje po vzpostavitvi tunela, in na nič drugega. Možnosti, zapisane v vaši lokalni datoteki, niso prizadete, prav tako ne promet aplikacij. Če ste upali, da boste procesu preprečili uporabo tunela, je to popolnoma napačno orodje in nobena kombinacija filtrov tega ne bo storila.

Ta obseg je koristen, ker pomeni, da lahko konfiguracijo strežnika pustite pri miru in vseeno delno zavrnete lokalno. To je tudi omejitev, ki jo velja zapisati v zahtevek: filter spreminja, kaj ta odjemalec sprejme, ne kaj strežnik ponuja. Nima nobenega vpliva na druge uporabnike istega profila. Prav tako ne preživi prehoda na drugega odjemalca, ki te možnosti ne izvaja, kar velja vedeti, preden na njej zgradite delovni tok.

Preden napišete vzorec, potrdite, kaj strežnik v resnici pošilja. Pri visoki podrobnosti odjemalec izpiše prejeti niz potisnjenih možnosti, in to je edini pošten vir za natančno besedilo, s katerim primerjate:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Potisnjeno vrstico berite kot seznam možnosti, ločenih z vejicami, in upoštevajte, da so imena možnosti in njihovi argumenti ločeni s presledki. Besedilo filtra se primerja s tem tokom, zato so presledki v naslednjem koraku tako pomembni.

Ujemanje je predpona, zato presledki odločijo o vsem

Primerjava je predpona niza, ne razčlenjeno ime možnosti. Zato "route" ustreza route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 in route-metric 100. En presledek na koncu ga zoži na družino, ki ste jo verjetno mislili, popolna predpona pa ga zoži še bolj na določen cilj.

Zadnja vrstica je tista, ki ujame ljudi pri delu z razdeljenim tunelom. Ohraniti svoj resolver je legitimna izbira in pomeni, da je vsako notranje ime zdaj odvisno od resolverja, ki ne vidi zasebne cone. To je posledica, ki jo sprejmete namenoma, ne stranski učinek, ki ga odkrijete v produkciji.

Ujemanje po predponi pomeni tudi, da se pravilo lahko pozneje tiho razširi. Ko strežnik doda novo možnost, ki se začne z vašim besedilom, vaš filter začne veljati zanjo, ne da bi kdo urejal vaš profil. To je način odpovedi, proti kateremu je treba načrtovati, omilitev pa je ujemanje čim večjega dela možnosti, ne čim manjšega.

Trije glagoli s tremi različnimi izidi

accept, ignore in reject niso trije zapisi iste zamisli. Razlikujejo se po tem, kaj odjemalec stori z ujemanjem, in po tem, ali kdo izve zanj.

ignore tiho zavrže ujemajočo se možnost, kar želite za nastavitev, ki ste jo namenoma zamenjali. reject jo zavrže in prisili odjemalca k pritožbi, kar želite, ko mora biti njena odsotnost vidna v dnevniku, ne pa odkrita pozneje. accept je pozitivna oblika, uporablja se, ko sestavljate seznam dovoljenih, ne pa odstranjujete posameznih možnosti.

Kateri koli glagol uporabite, filtri se uporabijo v vrstnem redu pojavljanja, zato dve prekrivajoči se pravili dasta rezultat, odvisen od vrstnega reda, ki ga je zelo težko pregledati. Držite eno pravilo na namen in v vsako vstavite najbolj natančno besedilo. Če potrebujete seznam dovoljenih, raje izberite nekaj pravil accept kot kup pravil ignore, ki se seštejejo v isto. Potem lahko pregledovalci preberejo datoteko od zgoraj navzdol in predvidijo izid, in to je edini test, ki se skalira.

Preverite uporabljeno pot in resolver, ne profila

Filter, ki je v datoteki videti pravilen, vas lahko vseeno pusti s tunelom, ki ne usmerja nič koristnega. Preverite učinek na delujočem sistemu, kjer so potisnjene možnosti že uporabljene ali zavržene:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Prvi dve vrstici vam povesta, ali je potisnjena privzeta pot prispela in koliko statičnih vnosov je preživelo. Poizvedba pri resolverju pokaže, kateri strežnik vmesnik tunela dejansko uporablja, in tam se običajno pojavi presenečenje z DNS. Zadnja vrstica odgovori na edino vprašanje, ki je za uporabnika pomembno.

Preizkusite obe smeri, dokler ste tam. Pravilo, ki ohrani vaš lokalni internet delujoč, a tiho pokvari notranje razreševanje imen, prestane površen pregled in spodleti pri prvi resnični nalogi, zato v isti preizkus vključite en notranji vir in eno javno spletišče.

Zabeležite izjemo in kdo je njen lastnik

Filter je izjema od zasnove operaterja, zato ga zapišite z razlogom in pregledno točko. »Prezre potisnjene poti, da ohrani lokalno privzeto« je pregledno; gola vrstica v profilu ni, in naslednja oseba jo bo izbrisala ali razširila z ugibanjem.

Tudi različica je tu pomembna. Vedenje ujemanja in natančna sprejeta sintaksa sta bila izpopolnjena v OpenVPN 2.4, 2.5 in 2.6, zato vzorec potrdite po priročniku za gradnjo, ki jo dobavljate, in ne po objavi na forumu o starejši različici. Priročnik OpenVPN 2.6 dokumentira to možnost in njeno pravilo ujemanja.

Na koncu se o izjemi dogovorite s tistim, ki upravlja strežnik. Odjemalski filter, ki nasprotuje namerni strežniški politiki, je podporni dogodek, ki čaka na naslednjo revizijo, in veliko ceneje ga je urediti pred pošiljanjem profila kot potem, ko nekdo opazi, da poti manjkajo.