Чому VPN може виглядати підключеним, коли нічого не працює

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

Три різні речі, які називають «підключено»

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

Зелений значок і мертвий тунель тому сумісні, а не суперечливі; вони повідомляють про різні об'єкти. Саме тому цю несправність знову й знову помилково діагностують як помилку клієнта.

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

Який лічильник доводить, що пакети пішли

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

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

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

Де розташована відмова після того, як лічильники пішли

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

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

Запишіть тригер, потім змініть одну річ

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

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

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