OpenVPN праз HTTP-праксі: спачатку чытайце адказ CONNECT
Праксі CONNECT перадае байты, таму абодва бакі патрэбуюць TCP. Чытайце 407, 403 і 503, перш чым вінаваціць сертыфікаты, і пакідайце праверку сервера ўключанай.
Наладзьце 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| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
Адказ класа 200 на CONNECT азначае, што паток існуе. Ён нічога не кажа пра тое, ці давераны сертыфікат шлюза, ці супадае агульны ключ, ці сапраўдны ўліковы запіс карыстальніка. Гэтыя праверкі адбываюцца потым, унутры патоку, і яны правальваюцца з уласнымі паведамленнямі кліента, а не з радком стану HTTP. Чытайце журнал кліента, каб знайсці першую OpenVPN падзею пасля рукапаціскання з праксі, а не апошні радок перад закрыццём акна.
Уліковыя даныя праксі і ўліковыя даныя VPN часта ёсць рознымі ідэнтычнасцямі, якімі кіруюць розныя каманды. 407 — гэта не дрэнны пароль уліковага запісу VPN, а адхілены сертыфікат — не праблема дазволаў праксі.
Што CONNECT не паказвае
Яўны тунель CONNECT — гэта не перахоп. Праксі перасылае байты і не завяршае TLS-сесію VPN, таму праверка сертыфіката сервера кліентам застаецца значнай і павінна быць уключанай. Выключэнне праверкі, каб прайсці праз праксі, вырашае іншую праблему, чым ваша.
Існуюць асобныя схемы, дзе арганізацыя свядома завяршае і інспектуе TLS. Яны патрабуюць уласнай канфігурацыі даверу і ўласнага рашэння па палітыцы, і яны не тое, што просіць звычайны радок http-proxy.
Кошт TCP унутры TCP
Перанос тунеля праз TCP захоўвае знешні паток упарадкаваным і з паўторнай перадачай, а ўнутраны трафік звычайна таксама TCP. Гэтыя два механізмы аднаўлення не ўзгадняюцца, таму адзін страчаны сегмент можа спыніць усё, што дзеліць гэты знешні паток, пакуль ён не будзе перададзены зноў. Гэта рэальны кампраміс дзеля сумяшчальнасці, а не бясплатнае паляпшэнне.
Выкарыстоўвайце шлях праз праксі, калі сетка не пакідае іншага выбару, і аддавайце перавагу прамому шляху UDP там, дзе палітыка дазваляе. У любым выпадку пасля змены пераканайцеся, што тыя ж праксі, прызначэнне і профіль дасягаюць наступнага этапу; браўзер, які загружае старонку па гэтым адрасе, выкарыстоўвае іншы пратакол і нічога не даказвае пра тунель.