Збережіть приватні маршрути й відмовтеся від переспрямування: розділений тунель OpenVPN

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

Видалення переспрямування — лише половина зміни

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

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

Якщо організація вимагає повний тунель, ніщо з цього не застосовується. Дизайн лише для приватних мереж належить розгортанням, де роздільна маршрутизація схвалена.

pull-filter — це збіг, а не перемикач

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

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

route-nopull — ширше рішення, ніж здається. Воно не дає клієнтові приймати проштовхнуті маршрути й параметри в стилі DHCP як групу, а це інша політика, ніж відфільтрувати один параметр.

Напишіть список маршрутів від застосунку назовні

Почніть із того, що користувач справді відкриває, потім додайте допоміжні частини. Застосунок за адресою 10.60.20.15 передбачає свою підмережу 10.60.0.0/16, а приватне ім я передбачає розв язувач, що на нього відповідає. Тому користувачеві, який попросив один застосунок, потрібні два призначення й одне рішення щодо DNS. Усе за межами цього списку за побудовою поза обсягом, і саме це робить політику придатною для перегляду.

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

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

Нехай DNS іде тим самим шляхом

Маршрут до розв язувача — не політика розв язувача. На клієнті systemd-resolved смисловий результат — це домен маршрутизації для приватного простору імен, що вказує на внутрішній розв язувач, і саме це змушує лише ці імена використовувати його. Клієнтові Windows потрібен натомість власний механізм політики просторів імен. Рядок DNS-сервера в профілі сам по собі не встановлює ні того, ні того.

Перевіряйте, що обрала операційна система, а не що запитав профіль. У Linux resolvectl status показує домен і сервер для кожного з єднання; у Windows таблиця політики просторів імен є еквівалентним доказом.

Тримайте розв язувач доступним через тунель, інакше політика вказує на адресу, яку не можна опитати. Адреса розв язувача, до якої тунель не дістає, перетворює робочу політику на тайм-аут.

Перевірте обидві половини під час повторного підключення

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

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