pull-filter v OpenVPN odpovídá víc než jen zamýšlené trase

Přidáte jeden řádek, abyste si zachovali místní výchozí trasu, a poté tunel už nedosáhne na interní DNS server. Řádek byl pull-filter ignore "route", což neznamená "ignoruj tuto trasu". Znamená to "zahodit každou tlačenou volbu, jejíž text začíná těmito pěti písmeny", a na běžném serveru to zahrnuje route-gateway, route-metric a route-ipv6 spolu se samotnými trasami. Kontrolní seznam níže je to, co projíždím, než se dotknu profilu, který musí používat někdo jiný.

Filtr působí jen na tlačené volby

pull-filter působí na řádky voleb, které server posílá po navázání tunelu, a na nic jiného. Volby zapsané ve vašem místním souboru jím nejsou dotčeny, stejně jako provoz aplikací. Pokud jste doufali, že zabráníte procesu používat tunel, je to úplně špatný nástroj a žádná kombinace filtrů to neudělá.

Tento rozsah je užitečný, protože znamená, že můžete nechat konfiguraci serveru na pokoji a přesto část z ní odmítnout lokálně. Je to také omezení, které stojí za to uvést v tiketu: filtr mění, co tento klient přijímá, ne co server nabízí. Nemá vliv na ostatní uživatele stejného profilu. Nepřežije ani přechod k jinému klientovi, který tuto volbu neimplementuje, což stojí za to vědět, než na něm postavíte pracovní postup.

Než pattern napíšete, ověřte, co server skutečně posílá. Při vysoké úrovni podrobností klient vypíše přijatý řetězec tlačených voleb, a to je jediný poctivý zdroj přesného textu, se kterým porovnáváte:

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

Čtěte tlačený řádek jako seznam voleb oddělených čárkami a všimněte si, že názvy voleb a jejich argumenty jsou odděleny mezerami. Text filtru se porovnává s tímto proudem, proto jsou mezery v dalším kroku tak důležité.

Shoda je prefix, takže mezery jsou celá hra

Porovnání je prefix řetězce, ne parsovaný název volby. Proto "route" odpovídá route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 a route-metric 100. Jedna mezera na konci to zúží na rodinu, kterou pravděpodobně myslíte, a úplný prefix to zúží dál na konkrétní cíl.

Poslední řádek je ten, který lidi chytá při práci s rozděleným tunelem. Ponechat si vlastní resolver je legitimní volba a znamená, že každé interní jméno teď závisí na resolveru, který nevidí privátní zónu. To je důsledek, který je třeba přijmout vědomě, ne vedlejší efekt, který se objeví v produkci.

Shoda podle prefixu také znamená, že se pravidlo může později tiše rozšířit. Když server přidá novou volbu začínající vaším textem, váš filtr na ni začne působit, aniž by kdokoli upravil váš profil. To je režim selhání, proti kterému je třeba navrhovat, a zmírněním je shodovat co největší část volby, ne co nejmenší.

Tři slovesa se třemi různými výsledky

accept, ignore a reject nejsou tři pravopisy téže myšlenky. Liší se v tom, co klient se shodou udělá, a v tom, zda se to někdo dozví.

ignore tiše zahodí odpovídající volbu, což chcete u nastavení, které jste záměrně nahradili. reject ji zahodí a přiměje klienta si stěžovat, což chcete, když má být její nepřítomnost vidět v logu, a ne objevena později. accept je kladná forma, používá se, když stavíte seznam povolených, ne když odstraňujete jednotlivé volby.

Ať použijete kterékoli sloveso, filtry se aplikují v pořadí, v jakém se objevují, takže dvě překrývající se pravidla dají na pořadí závislý výsledek, který se velmi těžko kontroluje. Držte jedno pravidlo na záměr a do každého dejte co nejkonkrétnější text. Pokud potřebujete seznam povolených, dejte přednost několika pravidlům accept před hromadou pravidel ignore, která dají totéž. Recenzenti pak mohou soubor přečíst shora dolů a předpovědět výsledek, a to je jediný test, který se škáluje.

Ověřte uplatněnou trasu a resolver, ne profil

Filtr, který v souboru vypadá správně, vás stále může nechat s tunelem, který nevede nic užitečného. Ověřte účinek na běžícím systému, kde už byly tlačené volby použity nebo zahozeny:

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/

První dva řádky vám řeknou zda dorazila tlačená výchozí trasa a kolik statických záznamů přežilo. Dotaz na resolver ukáže, který server rozhraní tunelu skutečně používá, a to je obvykle místo, kde se objeví překvapení s DNS. Poslední řádek odpovídá na jedinou otázku, na které uživateli záleží.

Otestujte oba směry, dokud tam jste. Pravidlo, které udrží váš místní internet funkční, ale tiše rozbije interní překlad jmen, projde povrchní kontrolou a selže u prvního skutečného úkolu, proto do stejného testu zařaďte jeden interní zdroj a jeden veřejný web.

Zapište výjimku a kdo ji vlastní

Filtr je výjimka z operátorova návrhu, takže ho zapište s důvodem a kontrolním bodem. "Ignoruje tlačené trasy, aby zachoval místní výchozí" je kontrolovatelné; holý řádek v profilu ne, a další člověk ho smaže nebo rozšíří odhadem.

Verze tu také hraje roli. Chování shody a přesná přijímaná syntaxe se ladily napříč OpenVPN 2.4, 2.5 a 2.6, proto pattern potvrďte podle manuálu pro sestavení, které dodáváte, a ne podle příspěvku na fóru o starší verzi. Manuál OpenVPN 2.6 tuto volbu a její pravidlo shody dokumentuje.

Nakonec výjimku odsouhlaste s tím, kdo server provozuje. Klientský filtr, který odporuje záměrné politice serveru, je support incident čekající na další audit, a je mnohem levnější ho vyřešit před odesláním profilu než poté, co si někdo všimne, že trasy chybí.