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

Зафіксуйте клієнт, перш ніж порівнювати мережі

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

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

Чотири етапи, чотири різні повідомлення про помилку

Підключення L2TP/IPsec проходить чотири етапи, і RFC 3193 описує схему, яка зв'язує перші два. Узгодження IKE — це місце, де відфільтрований шлях дає тихий тайм-аут. Автентифікація IPsec — це місце, де незбіг сертифіката або наперед спільного ключа дає натомість явну відмову. Встановлення тунелю L2TP — це місце, де вже встановлена асоціація безпеки все одно може нікуди не привести, а вхід PPP — це місце, де неправильні облікові дані нарешті дають видимий збій. Читайте журнал того етапу, який зупинився, а не останнього надрукованого рядка.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

Журнал strongSwan показує, чи дійшов обмін IKE до пропозиції і чи відповів партнер узагалі, що відокремлює доступність від політики. Журнал xl2tpd продовжується там, де закінчується IPsec, тому встановлена асоціація безпеки без чогось у цьому журналі вказує на етап L2TP. Запит маршруту підтверджує, що клієнт надсилає на ту адресу сервера, яку ви думаєте, і це ловить застарілу відповідь DNS, успадковану від попередньої мережі. Разом три виходи називають етап, а не симптом.

Порівняйте глибину NAT і поведінку помічника

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

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

Вихідний клієнт, вхідний сервер: дві різні проблеми

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

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

Схожі статті