Наладзьце 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 replyWhat it meansWhere to look next
407 Proxy Authentication RequiredThe proxy wants its own credentialsThe client's proxy auth options, not the VPN account
403 ForbiddenThe destination or method is not permittedThe proxy's access policy for that host and port
503 Service UnavailableThe proxy could not complete the upstream connectionThe 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 там, дзе палітыка дазваляе. У любым выпадку пасля змены пераканайцеся, што тыя ж праксі, прызначэнне і профіль дасягаюць наступнага этапу; браўзер, які загружае старонку па гэтым адрасе, выкарыстоўвае іншы пратакол і нічога не даказвае пра тунель.

Падобныя артыкулы