Серверге байланған профиль TLS проксиінің артында сәтсіз болады: қай буын?

Бір пайдаланушы қосыла алады, екіншісі қосыла алмайды, сол портал арқылы, сол күні. Екеуінің де серверге байланған профилі бар, екеуі де бір Access Server жинағында, және жалғыз айырмашылық — олардың профилі қашан жасалғаны. Бұл тануға тұрарлық үлгі, өйткені "серверге байланған" қосылу ретін емес, саясатты атайды. Access Server осы артефактінің екі буынын шығарды, ал TLS кері проксиі олардың тек бір жолының алдында тұр. Қай тармақта екеніңізді үш шарт анықтайды.

Екі буын, екі қосылу реті

2.8-ге дейін қолданылатын ескі дизайнда импортталған файл псевдопрофиль болып табылады. OpenVPN Connect оны HTTPS арқылы Access Server веб API-сінің алдында аутентификациялау үшін пайдаланады, уақытша пайдаланушыға байланған профиль мен сессия токенін алады, содан кейін ғана VPN орнатады. Екі транспорт ретімен жұмыс істейді, ал біріншісі қарапайым веб сұраныс.

2.9-бен енгізілген формат бұл қосылым сайынғы жүктеуді орындамайды. Бұл үйлесімді OpenVPN клиенттер пайдалана алатын жергілікті профиль, тек OpenVPN Connect қана емес. Оны жүктеу немесе URL арқылы импорттау әлі де HTTPS-ті қамтуы мүмкін — бұл жариялау қадамы, қосылым сайын уақытша профиль алу емес.

Жаңарту бұрын берілген профильдерді міндетті түрде қайта жазбайды, сондықтан ағымдағы сервер нұсқасы ескі артефактіні әлі де тарата алады. Сервер жинағы не мүмкін екенін айтады, бұл пайдаланушының не импорттағанын емес.

Сіздің тармағыңызды таңдайтын үш шарт

Бірінші шарт — артефактінің буыны. Файлды сұраңыз, оның қалай жасалғанын қараңыз және оны импорттаған клиент нұсқасын жазып алыңыз. Егер буынды файлдан анықтай алмасаңыз, сынақ тіркелгісі үшін берілген жаңа профиль сервердің бүгін не шығаратынын айтады, ал бұл сәтсіз пайдаланушыдағы ақпараттан өзгеше.

Екіншісі — алдыңғы бөлігіңіз шын мәнінде нені аяқтайтыны. TLS-ті түсіретін жетінші қабаттың HTTP кері проксиі төртінші қабаттың 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.
• Саясат өзгеріссіз жаңадан берілген профильді жергілікті соңғы нүктеге қарсы сынаңыз.