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