OpenVPN през HTTP прокси: прочетете първо отговора на CONNECT

Насочете VPN клиент към корпоративно HTTP прокси и първият полезен факт е, че проксито не говори протокола на VPN. То отваря обикновена TCP връзка към адреса, който сте посочили, и след това се отдръпва, оставяйки клиента и сървъра да проведат своя обмен през този поток. Всичко, от което клиентът се нуждае — от типа транспорт до слушателя на сървъра — трябва да съответства на тази подредба. Две несъответствия обясняват повечето откази: UDP профил, насочен към CONNECT прокси, и отговор на проксито, взет за VPN грешка.

Какво пренася проксито и какво не

Проксито е само транспортна стъпка. То не става прокси на браузъра ви, не кешира сайтовете, които посещавате през тунела, и не вижда вътрешния трафик, освен ако някой умишлено не е настроил инспекция. Тунелът, който отваря, е непрозрачен за него по замисъл.

Това също означава, че проксито не може да поправи сървър без съответстващ слушател. Разрешението да достигнете дестинация и услугата, която слуша на тази дестинация, са отделни факти и само първият принадлежи на администратора на проксито.

Транспортът трябва да е TCP в двата края

Обикновеното CONNECT прокси предава само поток от байтове , затова клиентът трябва да използва потоков транспорт. Фрагмент от клиент за този случай изглежда така:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

Страната на сървъра се нуждае от истински TCP слушател на порта, посочен в реда remote. Промяната на proto udp на proto tcp-client в профил създава клиент, който очаква поток; тя не създава потока от другата страна. Ако същият сървър отговаря и по UDP на този порт, това е различен слушател, а не втори режим на същия.

Където съществува отделна TCP инстанция, нейното тунелно устройство, адресен пул и маршрутизация са собствени ресурси. Копирането на работеща конфигурация и промяната на транспортната дума оставя тези ресурси сочещи към първоначалната инстанция, което дава връзка, която се удостоверява и после не маршрутизира нищо.

Прочетете отговора на проксито преди резултата на VPN

Първият обмен на клиента е ред на заявка с хоста и порта на дестинацията. Отговорът на този ред ви казва дали изобщо съществува поток от байтове и идва преди проверката на който и да е сертификат или идентификационни данни:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Отговор от клас 200 на CONNECT означава, че потокът съществува. Той не казва нищо за това дали сертификатът на шлюза е надежден, дали споделеният ключ съвпада или дали потребителският акаунт е валиден. Тези проверки се случват след това, вътре в потока, и се провалят със собствените съобщения на клиента, а не с HTTP ред за състояние. Прочетете журнала на клиента за първото OpenVPN събитие след ръкостискането с проксито, а не последния ред преди затварянето на прозореца.

Идентификационните данни за проксито и за VPN често са различни самоличности, управлявани от различни екипи. 407 не е лоша парола на VPN акаунта, а отхвърлен сертификат не е проблем с разрешенията на проксито.

Какво CONNECT не разкрива

Явният CONNECT тунел не е прихващане. Проксито препраща байтове и не прекратява TLS сесията на VPN, затова проверката на сървърния сертификат от клиента остава смислена и трябва да остане включена. Изключването на проверката, за да минете през прокси, решава различен проблем от вашия.

Съществуват отделни уредби, при които организация умишлено прекратява и инспектира TLS. Те изискват собствена конфигурация на доверие и собствено решение за политика и не са това, което иска обикновен ред http-proxy.

Цената на TCP в TCP

Пренасянето на тунела по TCP поддържа външния поток подреден и с повторно предаване, а вътрешният трафик обикновено също е TCP. Двата механизма за възстановяване не се координират, затова един загубен сегмент може да спре всичко, което дели този външен поток, докато не бъде предаден отново. Това е реален компромис за съвместимост, а не безплатно подобрение.

Използвайте пътя през прокси, когато мрежата не ви оставя алтернатива, и предпочитайте директен UDP път, където политиката позволява. Във всеки случай след промяна потвърдете, че същото прокси, дестинация и профил достигат следващия етап; браузър, който зарежда страница на този адрес, използва друг протокол и не доказва нищо за тунела.