route-gateway — це не redirect-gateway: що насправді змінюється

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

Видалений рядок був наступним хопом, а не перемикачем політики

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

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

Чотири важелі, чотири різні завдання

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

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

Фільтруйте проштовхнутий рядок, зберігайте наступний хоп

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

pull-filter ignore "redirect-gateway"

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

Читайте пошук, а не таблицю

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

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Варіант def1 варто знати, бо він залишає старий запис за замовчуванням видимим, поки пара напівзамовчуваних виграє пошук. Тому рядок 0.0.0.0/0 у виводі сам по собі нічого не доводить. Пошук відповідає на питання, на яке список лише здається відповідає.

DNS, IPv6 і приватний маршрут мають і далі працювати

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

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