Повний тунель FortiClient: маршрутизуємо лише офісну підмережу

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

Що встановив клієнт і чому зникла LAN

Почніть із читання таблиці, а не інтерфейсу клієнта. У macOS netstat -rn друкує всю таблицю, а route -n get default називає інтерфейс і метрику, які зараз перемагають; у Linux пара — ip route show і ip route get 8.8.8.8. Обидва відповідають на одне питання: який запис понесе пакет, що не збігається ні з чим конкретнішим.

Назва тунельного пристрою не фіксована. Профіль IKEv2 у macOS зазвичай показує utun з номером, клієнт SSL VPN показує ppp0, а OpenVPN показує tun0. Два маршрути за замовчуванням можуть бути присутні одночасно з різними метриками, а запис клієнта може перехопити керування лише після повторного підключення, а не в момент появи. Тому два знімки таблиці з різницею в п'ять хвилин можуть розповідати різні історії.

Чому маршрут за замовчуванням тунелю має піти першим

Ядро вибирає найдовший відповідний префікс, а коли кілька маршрутів однаково конкретні — той, у якого метрика нижча. Тому клієнт, який встановлює 0.0.0.0/0 з кращою метрикою, виграє кожен пункт призначення, не видаляючи початковий маршрут за замовчуванням, і саме тому фізичний маршрут досі в таблиці й досі пояснює збій. Видалення маршруту за замовчуванням тунелю першим відновлює попередню поведінку. Лише після цього префіксний маршрут через тунель робить те, що задумав автор.

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

Послідовність у macOS і в Linux

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

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

У Linux той самий порядок використовує інший інструмент: шлюз LAN для маршруту за замовчуванням і тунельний пристрій для офісного префікса. Стара команда route досі приймає старий синтаксис, але ip route — це форма, що відповідає чинній документації.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

Префікси, резолвер і DMZ, що залишається темною

Один префікс рідко покриває всю роботу. Сервери застосунків, мережі керування, DMZ і самі DNS-сервери можуть бути кожен у своєму діапазоні, тому перелічіть усі діапазони, які можете назвати, до початку роботи й перевіряйте запит поряд із кожним ping. Пункт призначення, виявлений посеред тесту, — це той, який забувають у журналі змін. Маршрут, який відповідає за адресою, але не за іменем, зазвичай є проблемою резолвера в костюмі маршрутизації.

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

У клієнта SSL у Linux є відмова, специфічна для одного поля, про яку варто знати: тунель підключається, офісна LAN відповідає, а один діапазон DMZ залишається темним. Бракує маршруту для цього діапазону через шлюз тунелю, а шлюз різниться між машинами, тому жорстко прописана адреса — це спосіб, у який ламається наступний ноутбук. Виведіть його зі стану клієнта й залиште команду самодокументованою:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Прочитайте два значення, перш ніж запускати. peer — це дальній кінець тунелю точка-точка, і саме ця адреса потрібна маршруту DMZ; у маршрутизованому тунелі еквівалент — інтерфейс або шлюз, який повідомляє клієнт. Якщо не з'являється ні те ні інше, клієнт не в тому режимі, який ви припускали.

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

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

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

Контрольний список короткий: прочитайте таблицю, видаліть маршрут за замовчуванням тунелю, відновіть маршрут за замовчуванням LAN, додайте кожен префікс, окремо виправте розв'язання імен і очікуйте, що маршрути повернуться після перепідключення.