Чому сам route-nopull залишає файловий сервер недоступним
Ігнорування проштовхнутих маршрутів — лише половина роздільного тунелю. Виберіть власника маршруту, додайте офісний префікс вручну і перевірте три потоки, перш ніж вважати це виправленим.
Файловий сервер відкривається нормально, а відеовиклик у сусідньому вікні починає підгальмовувати. Ніщо не повільне і жоден MTU не помилковий: ваш клієнт прийняв список маршрутів, який дав сервер, тому кожен пакет тепер виходить через офісний брандмауер. Виправлення — не ще один прапорець налаштування, а рішення про те, кому належить таблиця маршрутів клієнта. Це рішення належить одному місцю, і наведені нижче режими відмови підкажуть, яке місце ви насправді вибрали.
Вирішіть, кому належить таблиця маршрутів
Можливі три власники. Сервер може проштовхувати маршрути й шлюз за замовчуванням, і тоді клієнт встановлює все, що йому кажуть, і стає повним тунелем. Профіль клієнта може взяти володіння, відкидаючи проштовхування і несучи свої рядки маршрутів. Менеджер підключень робочого столу теж може володіти рішенням через свої властивості маршруту й маршруту за замовчуванням.
Кожен вибір відмовляє по-своєму, тому таблицю варто прочитати перед редагуванням профілю. Рядок, що збігається з вашим симптомом, — це власник, який у вас справді є.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Виберіть один і запишіть. Змішування двох залишає хост, чий шлях за замовчуванням суперечить власній документації, і наступний інженер не зможе сказати, який рівень переміг. Видаліть того, хто програв, явно.
route-nopull фільтрує проштовхування, він не додає маршрути
route-nopull належить профілю клієнта, і його порядок у цьому файлі не має значення, бо він лише відкидає значення, що надходять від сервера. Він відкидає проштовхнуті маршрути, включно з проштовхнутим маршрутом за замовчуванням, а тунель усе одно піднімається нормально.
Наслідок, який люди пропускають, — проштовхнуті параметри DHCP ідуть разом із ними. Надіслані сервером налаштування DNS теж відкидаються, тому внутрішні імена перестають розв'язуватися, хоча тунель здоровий і сервер доступний за адресою.
Це залишає тунель без шляху до офісного префікса, якщо ви самі не додасте його: route-nopull, за яким іде route 10.30.0.0 255.255.0.0 у тому самому профілі. Цей рядок несе адресу й маску; він не називає наступний хоп.
Альтернативна форма додає токен шлюзу, route 10.30.0.0 255.255.0.0 vpn_gateway, який указує запис на тунель за іменем. Імпортери різняться тим, чи перекладають вони цей варіант, тому перевірте збережене підключення, якщо запис відсутній у таблиці ядра.
Перевіряйте пошуком маршрутів, а не ping
ping повідомляє, що щось відповіло. Пошук маршруту повідомляє, який інтерфейс вибрало б ядро, і це те питання, яке ви насправді поставили. Чотири короткі команди відокремлюють відсутній маршрут від маршруту, що вказує на неправильний пристрій.
Прочитайте, що встановив тунель, за допомогою ip route show dev tun0. Повна відсутність виводу означає нуль маршрутів, що не є робочим роздільним тунелем, і це звичайний результат додавання фільтра без явного рядка.
Потім перевірте одну офісну адресу за допомогою ip route get 10.30.5.7 і одну звичайну інтернет-адресу за допомогою ip route get 1.1.1.1. Друга має назвати фізичний інтерфейс; якщо вона називає тунель, проштовхування взагалі не фільтрувалося.
Нарешті прочитайте ip rule, бо правило політики, залишене попередньою спробою, може перекрити щойно виправлену таблицю. Правильний профіль із застарілим правилом зверху виглядає точно як зламаний профіль. Видаліть правило, додане минулого разу, перш ніж додавати ще одне.
Перекривані підмережі виглядають як зламаний тунель
Два приватні діапазони можуть бути однаковими з погляду клієнта, і саме там роздільний тунель звинувачують у тому, чого він не спричинив. Якщо офіс видає той самий префікс, який використовує ваш домашній маршрутизатор, маршрут тунелю покриває маршрутизатор, і домашня мережа ніби зникає.
Порівняйте адресу на своєму інтерфейсі з маршрутом, який встановлює профіль, використовуючи звичайний список адрес, перш ніж щось змінювати. Перекриття реальне, і жодна опція профілю його не вирішує. Що ви можете виправити — це іменування, щоб наступна людина бачила два діапазони замість одного.
Чесні виправлення — перенумерувати один бік або транслювати адреси в офісі. Прикріплення одного маршруту хоста до маршрутизатора працює, доки адреса маршрутизатора не зміниться, а потім стає другою загадкою поверх першої.
Зробіть так, щоб рішення пережило перепідключення
Записи, введені вручну, не переживають перепідключення, а менеджер підключень перебудовує таблицю щоразу, коли профіль запускається. Помістіть рішення туди, де створюється підключення, чи то профіль, чи то збережені налаштування менеджера. Потім один раз навмисно перезапустіть підключення, замість того щоб виявляти поведінку під час виклику. Профіль, який працює лише до наступного перепідключення, не завершений.
Перевірте три шляхи одразу: офісний хост за буквальною адресою, той самий хост за іменем і звичайний публічний сайт. Середній залежить від служби імен, яку ви налаштували після відмови від проштовхнутих параметрів DNS, і саме він тихо відмовляє.