Перевірити, що розділений тунель працює: одного результату IP недостатньо

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

Міф: запит адреси доводить покриття

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

Сторінка адреси також не може показати маршрут, резолвер або політику відмови. Ставтеся до неї як до одного спостереження, а не як до вироку.

Перевірте включений і виключений потік

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

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Тому перевірка в неправильному застосунку може показати протилежне тому, що задумано. Запишіть чотири поля для обох сторін, перш ніж робити будь-який висновок.

Додайте DNS і сценарій відмови

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

curl -s https://ifconfig.me
nslookup intranet.example

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

Повторіть після зміни стану

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

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

Що має встановити результат

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

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