VPN на роутері виглядає нормально після відключення електроенергії? Перевірте ці чотири рівні

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

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

Перший рівень: чи справді повернувся WAN

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

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

Другий рівень: перевірте годинник до сертифіката

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

date -u
chronyc tracking

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

Третій рівень: прочитайте, що каже тунель

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

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

Четвертий рівень: тестуйте з пристрою нижче

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

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

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

Що виправити, щоб наступне відключення було коротшим

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

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