Профіль підключення SoftEther: перевірте шість полів перед імпортом
Шість полів вирішують, чи працюватиме профіль SoftEther. Перевірте кінцеву точку, порт, протокол, концентратор, користувача й роль по черзі, а потім перевірте, до чого ви насправді приєдналися.
Імпорт профілю вдається, але автентифікація не проходить, бо файл указує на Virtual Hub, до якого обліковий запис ніколи не приєднувався. У файлі немає нічого пошкодженого; він описує конфігурацію, для якої облікові дані не видавалися. Шість полів вирішують, чи може імпорт працювати: ім’я хоста, порт, протокол, Virtual Hub, ідентичність користувача й те, чи не передав вам хтось помилково облікові дані адміністратора. Перевірки з першої по третю по черзі охоплюють ці поля, а останні дві стосуються самого файлу й того, до чого ви насправді приєдналися.
Перевірка 1: ім’я хоста й порт
Прочитайте ім’я хоста, порт і заявлений метод доступу, перш ніж щось імпортувати. Власний прослуховувач SoftEther зазвичай відповідає на TCP 443, а 992 і 5555 — альтернативи, які оператори відкривають для клієнтів за обмежувальними мережами. Профіль, націлений на порт, що обслуговує вебсайт або іншу службу, зазнає невдачі до автентифікації й повідомляє про помилку як про проблему з обліковими даними. Порівняйте пару з тим, що оператор публікує для цієї кінцевої точки, а не зі списком із каталогу, який хтось зібрав минулого року. Якщо ім’я хоста розв’язується в адресу, яку оператор ніколи не згадує, зупиніться там, бо наступний крок надішле облікові дані на цю адресу.
Порт 443 — спільна територія, тож сам порт нічого не доводить про службу за ним. Клієнт SoftEther розділяє їх за рукостисканням протоколу, тому профіль може вказувати на правильний порт і все ж завершитися на вебсервері. Ця помилка в журналі клієнта виглядає як неправильний пароль, хоча пароль ніколи не перевірявся.
Запишіть кінцеву точку як ім’я хоста, порт і метод, у цьому порядку. Ця трійка — те, що можна перевірити без підключення, і те, що варто цитувати, коли ви питаєте оператора, чи працює прослуховувач. Усе, що ви не можете доповнити з опублікованого джерела, залишається неперевіреним, а не припущеним.
Перевірка 2: протокол визначає клієнт
Сервер, що пропонує кілька методів доступу, не перетворює один експортований файл на профіль, який може відкрити кожен клієнт. Each method has its own format, its own client and its own failure mode, а їх змішування породжує помилки, що звучать як проблеми з обліковими даними. Визначте, який метод заявлено у файлі, перш ніж вирішувати, який клієнт його відкриє.
Таблиця нижче перелічує звичайні порти й те, що насправді потребує кожен метод. Порти — вибір оператора, тож сприймайте їх як типові значення, а не як факти про конкретний сервер. Власний профіль SoftEther імпортує клієнт SoftEther, пакет ovpn належить OpenVPN, а профілі SSTP чи L2TP обробляє сама операційна система. Встановлення другого клієнта, щоб відкрити файл, який відкидає перший, зазвичай перетворює зрозумілу помилку на заплутану.
| Access method | Typical port | What the client needs |
|---|---|---|
| SoftEther native | TCP 443, 992 or 5555 | The SoftEther client and a hub name |
| OpenVPN | UDP or TCP 1194 | An ovpn profile and an OpenVPN client |
| SSTP | TCP 443 | Operating system support |
| L2TP over IPsec | UDP 500 and 4500 | Operating system support and the shared key |
Читайте оголошення всередині файлу, а не розширення. Файл, названий за OpenVPN, за визначенням є профілем OpenVPN, тоді як профіль SoftEther — невелика конфігурація, яку імпортує клієнт SoftEther, і ці два не взаємозамінні. Якщо заявлений метод — той, який ви не можете обслужити, це відповідає на питання про імпорт.
Перевірка 3: концентратор, користувач і роль адміністратора
Для власного доступу профіль указує Virtual Hub і користувача в ньому. A hub is a logical VPN server instance with its own users and its own settings, а користувач є членом цього концентратора з власною автентифікацією. Ні те, ні інше не є адмініструванням сервера, яке керує прослуховувачами, концентраторами й кожним користувачем розгортання. Клієнтський профіль ніколи не повинен надходити з цим контролем у комплекті. Коли хтось надсилає вам облікові дані адміністратора, щоб клієнт запрацював, конфігурація неправильна, незалежно від того, чи він підключається.
Тримайте ці три речі окремо, документуючи підключення, бо відкликаються вони по-різному. Видалення користувача концентратора припиняє доступ однієї особи й залишає решту розгортання недоторканою, тоді як ротація облікових даних адміністратора зачіпає все. Ця різниця — також причина заперечувати проти одного спільного користувача концентратора для команди, адже одні облікові дані означають одну подію відкликання для всіх.
Перевірка 4: файл такий чутливий, як і те, що він несе
Залежно від формату профіль може нести збережений пароль, сертифікат або заздалегідь розділений ключ. Ставтеся до експорту як до секрету, поки він існує, бо копія, яку ви прикріплюєте до заявки, — це копія, яку може імпортувати хтось інший. Видаліть облікові дані перед поширенням або поділіться повторно створеним профілем із новим секретом. Чутливість файлу походить від його вмісту, а не від розширення чи розміру.
Підтверджуйте кінцеву точку каналом, який публікує оператор, а позначку з каталогу вважайте неперевіреною. Прапор країни й ім’я хоста в публічному списку вузлів обирає той, хто надіслав запис, тож ні те, ні інше не встановлює, хто керує сервером. Якщо профіль походить із публічного каталогу, це причина для більшої кількості перевірок, а не меншої.
Запишіть, звідки прийшов файл і коли ви його отримали. Коли підключення згодом поводиться інакше, походження — перше, що ви порівнюєте з перевіреною кінцевою точкою. Профіль без походження — це профіль, який ви не можете перевірити.
Архівуйте копію, яку ви перевірили, а не ту, яку знайшли пізніше. Два файли з однаковим ім’ям і різними кінцевими точками — так робочий імпорт перетворюється на звернення до підтримки. Тримайте перевірену копію поруч із нотаткою про її походження.
Перевірка 5: перевіряйте застосунок, а не індикатор стану
Після імпорту перевірте застосунок, який вам справді потрібен, а не індикатор підключення. Успішна автентифікація доводить, що облікові дані працюють, а не що очікувані маршрути чи DNS прийшли із сеансом. Підключіться, а потім скористайтеся службою, до якої профіль мав діставатися.
Огляньте призначені маршрути й DNS-сервери та занотуйте, які призначення обходять тунель, якщо в задумі є розділення. Потім повторіть з одним призначенням, яке мало б бути виключене, бо розділений тунель, що надсилає все через тунель, усе одно проходить тест з одним призначенням. Якщо приватний ресурс не працює, підозрюваний — маршрут, а не облікові дані. Запишіть чотири результати: автентифікацію пройдено, служба доступна, маршрути як очікувалося, виключене призначення виключене.
Порівняйте всі чотири результати з тим, що оператор обіцяв для цього концентратора. Сеанс, який проходить автентифікацію, коли виключене призначення теж доступне, означає, що розділення не діє і профіль тут ні до чого. Виправте очікування або політику концентратора, а потім повторіть чотири перевірки в тому самому порядку.