Чи повне тунелювання простіше за довгий список розділеного тунелювання?

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

Почніть із підрахунку правил, які ви підтримуєте

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

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

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

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

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

ip -s link show dev tun0
conntrack -C
ss -s

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

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

Підтвердьте, що локальні служби й приватний DNS досі працюють

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

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

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

Перенесіть один профіль і перевірте межі

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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