Чому ваше правило split tunnel перестало відповідати сервісу

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

Що фіксує правило і що повертає DNS

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

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

Три способи, якими ламається збіг

Очевидний випадок — сервіс, що переїхав: оператор дав йому нову адресу, DNS пішов слідом, а виняток ні. Другий — родина адрес, яку правило ніколи не покривало, що буває, коли ім'я починає повертати записи AAAA, які виняток лише для IPv4 ігнорує. Третій — різниця resolver: внутрішній і публічний вигляд можуть повертати різні адреси для одного імені, тож адреса, яку використовує застосунок, не та, з якою ви тестували.

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

Прочитайте пункт призначення, який застосунок справді використовує

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

Виправте механізм, а не симптом

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

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

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

Перевірте обидві половини задуму

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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