OpenVPN sa pamamagitan ng proxy HTTP: basahin muna ang tugon ng CONNECT
Nagpapasa ng bytes ang proxy CONNECT, kaya kailangan ng TCP sa magkabilang dulo. Basahin ang 407, 403 at 503 bago sisihin ang mga sertipiko, at panatilihing naka-on ang beripikasyon ng server.
Itutok ang isang kliyente ng VPN sa isang corporate HTTP proxy, at ang unang kapaki-pakinabang na katotohanan ay hindi nagsasalita ang proxy ng protocol ng VPN. Nagbubukas ito ng ordinaryong koneksyon TCP patungo sa address na binanggit mo at pagkatapos ay tumatabi, hinahayaang ang kliyente at ang server ang gumawa ng kanilang sariling palitan sa stream na iyon. Lahat ng kailangan ng kliyente, mula sa uri ng transport hanggang sa tagapakinig ng server, ay dapat tumugma sa ayos na iyon. Dalawang hindi pagtutugma ang nagpapaliwanag sa karamihan ng mga pagkabigo: isang profile UDP na nakaturo sa isang proxy CONNECT, at isang tugon ng proxy na napagkamalang error ng VPN.
Ano ang dinadala ng proxy, at ano ang hindi
Ang proxy ay isang hakbang ng transport lamang. Hindi ito nagiging proxy ng browser mo, hindi nito naka-cache ang mga site na binibisita mo sa tunnel, at hindi nito nakikita ang panloob na trapiko maliban kung may sadyang nag-configure ng inspeksyon. Ang tunnel na binubuksan nito ay malabo para sa kanya ayon sa disenyo.
Ibig sabihin din nito na hindi kayang ayusin ng proxy ang isang server na walang katugmang tagapakinig. Ang pahintulot na maabot ang isang destinasyon at isang serbisyong nakikinig sa destinasyong iyon ay dalawang magkaibang katotohanan, at ang una lamang ang pag-aari ng administrador ng proxy.
Dapat TCP ang tagapagdala sa magkabilang dulo
Ang karaniwang proxy CONNECT ay nagpapasa lamang ng stream ng bytes , kaya dapat gumamit ang kliyente ng stream transport. Ang fragment ng kliyente para sa kasong iyon ay ganito ang hitsura:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Kailangan ng panig ng server ang tunay na tagapakinig TCP sa port na binanggit sa linyang remote. Ang pagpapalit ng proto udp sa proto tcp-client sa isang profile ay lumilikha ng kliyenteng umaasa ng stream; hindi nito nililikha ang stream sa kabilang panig. Kung ang parehong server ay sumasagot din sa UDP sa port na iyon, ibang tagapakinig iyon, hindi pangalawang mode ng pareho.
Kung saan may hiwalay na instance TCP, ang device ng tunnel nito, pool ng address at routing ay sariling mapagkukunan. Ang pagkopya ng gumaganang configuration at pagbabago ng salita ng transport ay iniiwan ang mga mapagkukunang iyon na nakaturo sa orihinal na instance, na gumagawa ng koneksyong nagpapatunay at pagkatapos ay walang niruruta.
Basahin ang tugon ng proxy bago ang resulta ng VPN
Ang unang palitan ng kliyente ay isang linyang kahilingan na nagngangalan sa host at port ng destinasyon. Ang tugon sa linyang iyon ay nagsasabi kung may stream ng bytes sa lahat, at dumarating ito bago suriin ang anumang sertipiko o kredensyal:
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 |
Ang tugon na nasa klase 200 sa CONNECT ay nangangahulugang may stream. Wala itong sinasabi tungkol sa kung mapagkakatiwalaan ang sertipiko ng gateway, kung tugma ang shared key, o kung wasto ang account ng user. Nagaganap ang mga pagsusuring iyon pagkatapos, sa loob ng stream, at nabibigo sila sa sariling mensahe ng kliyente kaysa sa isang linyang status ng HTTP. Hanapin sa log ng kliyente ang unang OpenVPN pangyayari pagkatapos ng handshake sa proxy, hindi ang huling linya bago isara ang window.
Ang kredensyal ng proxy at ang kredensyal ng VPN ay madalas na magkaibang pagkakakilanlan sa kamay ng magkaibang team. Ang 407 ay hindi maling password ng account ng VPN, at ang tinanggihang sertipiko ay hindi problema sa pahintulot ng proxy.
Ano ang hindi isinisiwalat ng CONNECT
Ang tahasang tunnel CONNECT ay hindi interception. Nagpapasa ang proxy ng bytes at hindi tinatapos ang sesyon TLS ng VPN, kaya nananatiling makabuluhan ang beripikasyon ng sertipiko ng server ng kliyente at dapat itong manatiling naka-on. Ang pag-off ng beripikasyon upang makalampas sa proxy ay nilulutas ang ibang problema kaysa sa iyo.
May hiwalay na mga kaayusan kung saan sadyang tinatapos at sinusuri ng isang organisasyon ang TLS. Kailangan nila ng sarili nilang configuration ng tiwala at sarili nilang desisyon sa patakaran, at hindi sila ang hinihingi ng ordinaryong linyang http-proxy.
Ang gastos ng TCP sa loob ng TCP
Ang pagdadala ng tunnel sa ibabaw ng TCP ay nagpapanatili sa panlabas na stream na maayos at may retransmission, at ang panloob na trapiko ay karaniwang TCP din. Hindi nag-uugnay ang dalawang mekanismo ng pagbawi, kaya ang isang nawalang segment ay maaaring magpahinto sa lahat ng nagbabahagi ng panlabas na stream na iyon hanggang sa maipadala itong muli. Ito ay tunay na palitan para sa pagiging compatible, hindi libreng upgrade.
Gamitin ang daan sa proxy kapag walang iniiwang alternatibo ang network, at piliin ang direktang daan UDP kung saan pinapayagan ng patakaran. Sa anumang kaso, pagkatapos ng pagbabago tiyakin na ang parehong proxy, destinasyon at profile ay nakarating sa susunod na yugto; ang browser na naglo-load ng pahina sa address na iyon ay gumagamit ng ibang protocol at walang pinatutunayan tungkol sa tunnel.