Груповий секрет vpnc чи ваш логін: яке поле що приймає?
Профіль vpnc запитує ID групи, груповий секрет і логін XAuth, а люди вводять пароль облікового запису не в те поле. Зіставте кожне поле з його роллю.
Коли хтось уперше дає вам профіль vpnc, діалог облікових даних запитує чотири речі й читається так, ніби хоче один пароль. Це не так: спільний груповий секрет і індивідуальний логін XAuth — різні значення з різними власниками, а пароль облікового запису в полі групи дає помилку, схожу на неправильний пароль, а не на неправильне поле. Правильно вибудувати це зіставлення — уся задача тут. Протокол під усім цим — чужий проєкт міграції, тому ніщо з цього не є аргументом будувати нові тунелі IKEv1.
Два секрети, два власники, один діалог
Груповий секрет належить профілю шлюзу. Усі, хто підключається через цей профіль, використовують те саме значення, і саме тому він не може ідентифікувати людину й не може бути відкликаний в одного ноутбука без зміни для всіх інших користувачів профілю. Ім'я користувача й пароль XAuth належать людині, і шлюз перевіряє їх на другому етапі, коли зв'язок IPsec уже встановлено.
Саме цю двоетапну форму люди проґавлять. Встановлення тунелю й автентифікація користувача — різні обміни з різними вхідними даними, тому клієнт, який так і не доходить до запиту облікових даних, зовсім не зазнав невдачі під час входу. Читайте діалог як два стовпці, а не один: значення рівня профілю ліворуч, особисті значення праворуч. Коли з'єднання не вдається, останній заповнений вами стовпець не обов'язково винний.
Зіставляйте поля за роллю, а не за підписом
vpnc називає свої директиви в документації проєкту, а кожен графічний інтерфейс перейменовує їх. Перекладіть роль кожного значення, і підписи перестануть мати значення:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Інтерфейс, який поруч із полем групи показує «Ім'я користувача» і «Пароль», не помиляється — це ті самі три значення під іншими назвами. Ламається те, коли поле заповнюють тому, що значення в нього вміщується. Груповий секрет, вставлений як пароль користувача, автентифікує профіль і потім зривається на етапі користувача; пароль облікового запису, вставлений як груповий секрет, зривається раніше, до будь-якого запиту, і відправляє людей шукати проблему в міжмережевих екранах, хоча вона живе в текстовому полі.
Чим ідентифікатор групи не є
Слово «група» штовхає до неправильного прочитання. Ідентифікатор групи тут — це селектор, який каже шлюзу, яку конфігурацію профілю застосувати; він нічого не говорить про членство в каталозі, а збіжний іменник з обох боків залишається випадковістю, доки оператор його не підтвердить. Авторизація відбувається після успішного XAuth, її визначає те, що шлюз налаштований запитувати, і нічого з цього не видно в клієнтському діалозі.
Та сама обережність стосується групового секрету. Знати його — не ідентичність, а кружляння одного секрету в команді — операційне рішення з наслідками, які клієнт не може вам показати.
Розберіться з двозначною інструкцією до підключення
Старі нотатки про передачу часто містять рядок на кшталт «використовуйте виділений публічний IP». Ця фраза може означати адресу, з якої список дозволів на тому боці очікує прихід вашого трафіку, — це властивість виходу мережі оператора, і вона ніяк не пов'язана з кінцевою точкою, яку ви вводите в полі шлюзу. Запитайте, що з двох мається на увазі, перш ніж значення кудись піде. Заповнене навпаки, воно надсилає кожен пакет на адресу, яка ніколи не відповідає, і отриманий тайм-аут читається як заблокований порт.
Запросіть чотири речі перевіреним каналом організації: який клієнт і протокол підтримуються, яку кінцеву точку використовувати, яку особу представить шлюз і як передаються облікові дані. Тримайте справжні секрети поза скриншотами, заявками й спільними нотатками з усунення неполадок. Не вимикайте перевірки сертифікатів і не вставляйте старий список шифрів, щоб інакше налаштований сервіс виглядав сумісним, адже з'єднання, що працює лише завдяки ослабленню перевірки, — не те з'єднання, яке вас просили побудувати.
Тримайте старий профіль чесним
IKEv1 застарів, і RFC 9395 — документ, на який посилаються, коли постає питання міграції. Успішне зіставлення полів не доводить, що протоколу місце в новому дизайні; воно купує працездатне з'єднання, поки заміна запланована, плюс письмовий обсяг і власника цієї міграції.
Потім перевіряйте за вимогою, а не за діалогом. Після підключення переконайтеся, що інтерфейс тунелю має очікувану адресу і що внутрішнє призначення маршрутизується через нього; якщо початкова вимога називала адресу виходу для списку дозволів, підтвердьте й цю адресу, бо це інший факт, ніж піднятий тунель. Профіль, який правильно автентифікується й нічого не маршрутизує, все одно не виконав завдання, для якого створений.