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 патека каде политиката дозволува. Во секој случај, по промена проверете дали истите прокси, дестинација и профил стигнуваат до следната фаза; прелистувачот што вчитува страница на таа адреса користи друг протокол и не докажува ништо за тунелот.