Серверт түгжигдсэн профайл 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 дамжуулагч ч мөн биш. 443 порт дээрх Access Server-ийн ердийн зохион байгуулалт нь 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.
• Бодлогыг өөрчлөхгүйгээр шинээр олгосон профайлыг төрөлх төгсгөлийн цэгт туршиж үз.