Профіль, прив'язаний до сервера, не працює за проксі TLS: яке покоління?

Один користувач підключається, а інший ні, через той самий портал, того самого дня. В обох є прив'язані до сервера профілі, обидва на одній збірці Access Server, і єдина різниця — коли було створено їхній профіль. Це той шаблон, який варто розпізнавати, бо "прив'язаний до сервера" називає політику, а не послідовність підключення. Access Server випустив два покоління цього артефакту, і зворотний проксі TLS стоїть лише перед одним із їхніх шляхів. Три умови визначають, на якій гілці ви перебуваєте.

Два покоління, дві послідовності підключення

У старішій схемі, чинній до 2.8, імпортований файл є псевдопрофілем. OpenVPN Connect використовує його для автентифікації у веб-API Access Server через HTTPS, отримує тимчасовий профіль, прив'язаний до користувача, і токен сесії, і лише потім встановлює VPN. Два транспорти працюють послідовно, і перший — звичайний веб-запит.

Формат, запроваджений із 2.9, не виконує цього початкового завантаження для кожного підключення. Це рідний профіль, який можуть використовувати сумісні OpenVPN клієнти, а не лише OpenVPN Connect. Його завантаження або імпорт за URL усе ще може включати HTTPS — це крок публікації, а не отримання тимчасового профілю для кожного підключення.

Оновлення не обов'язково переписує вже видані профілі, тож поточна версія сервера все ще може видавати старий артефакт. Збірка сервера каже, що можливо, а не що імпортував цей користувач.

Три умови, які вибирають вашу гілку

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

Друга — що ваш фронтенд насправді завершує. Зворотний HTTP-проксі сьомого рівня, який знімає TLS, — не той самий об'єкт, що переадресатор TCP четвертого рівня, і переадресатор UDP теж. Звична схема Access Server на порту 443 змушує демон OpenVPN TCP розпізнавати трафік браузера і передавати його вебсервісам, тому вставлення стороннього термінатора HTTPS спереду не зберігає обробку протоколу цим демоном. Спільний номер 443 не робить дві схеми еквівалентними.

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

Коли артефакт старий: початкове завантаження збоїть першим

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

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

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

Коли артефакт новий: читайте канал керування

З профілем у стилі 2.9 клієнт іде прямо до рідного кінцевого пункту VPN. Дослідіть кінцеві пункти в профілі, використовуваний транспорт і помилку каналу керування. Якщо клієнт ніколи не надсилає HTTP-запит, це відповідає схемі і не є симптомом.

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

Пропуск TLS для одного потоку — вузька схема. Він не дає переадресації UDP і не відтворює власну поведінку демона щодо переадресації сервісів на 443. Якщо ваш фронтенд робить одне з цього, скажіть яке, бо виправлення інше.

Виправлення, які залишаються вузькими

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

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

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

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