pull-filter в OpenVPN збігається з більшим, ніж задуманий маршрут

Ви додаєте один рядок, щоб зберегти локальний маршрут за замовчуванням, і після цього тунель більше не досягає внутрішнього DNS-сервера. Цей рядок був pull-filter ignore "route", що не означає «ігноруй цей маршрут». Це означає «відкинь кожну проштовхувану опцію, текст якої починається з цих п'яти літер», і на звичайному сервері це включає route-gateway, route-metric і route-ipv6 разом із самими маршрутами. Контрольний список нижче — це те, що я проходжу перед тим, як торкатися профілю, яким має користуватися хтось інший.

Фільтр діє лише на проштовхувані опції

pull-filter діє лише на рядки опцій, які сервер надсилає після встановлення тунелю, і ні на що інше. Опції, записані у вашому локальному файлі, від нього не зачіпаються, як і трафік застосунків. Якщо ви сподівалися перешкодити процесу використовувати тунель, це цілком не той інструмент, і жодна комбінація фільтрів цього не зробить.

Цей обсяг корисний, бо дає змогу не чіпати конфігурацію сервера й усе ж локально відмовитися від її частини. Це також обмеження, яке варто зафіксувати в заявці: фільтр змінює те, що приймає цей клієнт, а не те, що пропонує сервер. Він не впливає на інших користувачів того самого профілю. Він також не переживе переходу на інший клієнт, який не реалізує цю опцію, і це варто знати перед тим, як будувати на ньому робочий процес.

Перш ніж писати шаблон, підтвердьте, що сервер насправді надсилає. За високого рівня деталізації клієнт друкує отриманий рядок проштовхуваних опцій, і це єдине чесне джерело точного тексту, з яким ви порівнюєте:

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

Читайте проштовхуваний рядок як список опцій, розділених комами, і зверніть увагу, що назви опцій та їхні аргументи розділені пробілами. Текст вашого фільтра порівнюється з цим потоком, тому пробіли такі важливі на наступному кроці.

Зіставлення — це префікс, тому пробіли вирішують усе

Порівняння — це префікс рядка, а не розібрана назва опції. Тому "route" збігається з route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 і route-metric 100. Один пробіл у кінці звужує його до родини, яку ви, ймовірно, мали на увазі, а повний префікс звужує ще більше до конкретного призначення.

Останній рядок — той, що ловить людей під час роботи з розділеним тунелем. Тримати власний резолвер — законний вибір, і це означає, що кожне внутрішнє ім'я тепер залежить від резолвера, який не бачить приватної зони. Це наслідок, який приймають свідомо, а не побічний ефект, який виявляють у виробництві.

Зіставлення за префіксом означає також, що правило може згодом тихо розширитися. Коли сервер додає нову опцію, що починається з вашого тексту, ваш фільтр починає застосовуватися до неї, хоча ніхто не редагував профіль. Це і є режим відмови, проти якого треба проєктувати, а пом'якшення — збігатися з якомога більшою частиною опції, а не з якомога меншою.

Три дієслова з трьома різними результатами

accept, ignore і reject — не три написання однієї ідеї. Вони різняться тим, що клієнт робить зі збігом, і тим, чи хтось про це дізнається.

ignore тихо відкидає відповідну опцію, що потрібно для налаштування, яке ви свідомо замінили. reject відкидає її й змушує клієнт скаржитися, що потрібно, коли її відсутність має бути видимою в журналі, а не виявленою пізніше. accept — позитивна форма, застосовується, коли ви будуєте список дозволених, а не видаляєте окремі опції.

Яке б дієслово ви не використовували, фільтри застосовуються в порядку появи, тому два правила, що перекриваються, дають залежний від порядку результат, який дуже важко переглядати. Тримайте одне правило на один намір і в кожне вміщуйте найконкретніший текст. Якщо потрібен список дозволених, віддайте перевагу кільком правилам accept перед купою правил ignore, які дають те саме. Тоді рецензенти можуть прочитати файл згори донизу й передбачити результат, і це єдиний тест, який масштабується.

Перевіряйте застосований маршрут і резолвер, а не профіль

Фільтр, який виглядає правильним у файлі, усе ще може залишити вас із тунелем, що не маршрутизує нічого корисного. Перевірте ефект у робочій системі, де проштовхувані опції вже застосовано або відкинуто:

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/

Перші два рядки кажуть вам, чи надійшов проштовхуваний маршрут за замовчуванням і скільки статичних записів уціліло. Запит до резолвера показує, який сервер насправді використовує інтерфейс тунелю, і зазвичай саме там виникає несподіванка з DNS. Останній рядок відповідає на єдине питання, важливе для користувача.

Перевірте обидва напрямки, поки ви там. Правило, яке зберігає ваш локальний інтернет робочим, але тихо ламає внутрішнє розв'язання імен, проходить поверхневу перевірку й зазнає невдачі на першому справжньому завданні, тому включіть до того самого тесту один внутрішній ресурс і один публічний сайт.

Запишіть виняток і його власника

Фільтр — це виняток із задуму оператора, тому запишіть його з причиною й точкою перегляду. «Ігнорує проштовхувані маршрути, щоб зберегти локальний за замовчуванням» піддається перевірці; голий рядок у профілі — ні, і наступна людина видалить його або розширить навмання.

Версія тут також важлива. Поведінка зіставлення й точний прийнятний синтаксис удосконалювалися в OpenVPN 2.4, 2.5 і 2.6, тому підтвердьте шаблон за посібником тієї збірки, яку ви постачаєте, а не за дописом на форумі про старішу версію. Посібник OpenVPN 2.6 документує цю опцію та її правило зіставлення.

Наостанок узгодьте виняток із тим, хто керує сервером. Клієнтський фільтр, що суперечить навмисній політиці сервера, — це інцидент підтримки, який чекає на наступний аудит, і набагато дешевше залагодити його до відправлення профілю, ніж після того, як хтось помітить відсутність маршрутів.