OpenVPN melalui proksi HTTP: baca dahulu balasan CONNECT

Halakan klien VPN ke proksi HTTP korporat, dan fakta berguna pertama ialah proksi tidak bertutur protokol VPN. Ia membuka sambungan TCP biasa ke alamat yang anda nyatakan dan kemudian menyingkir, membiarkan klien dan pelayan melakukan pertukaran mereka sendiri melalui aliran itu. Semua yang diperlukan klien, daripada jenis pengangkutan hingga pendengar pelayan, mesti sepadan dengan susunan itu. Dua ketidakpadanan menjelaskan kebanyakan kegagalan: profil UDP yang ditujukan kepada proksi CONNECT, dan balasan proksi yang disalah anggap sebagai ralat VPN.

Apa yang dibawa proksi, dan apa yang tidak

Proksi hanyalah satu lompatan pengangkutan. Ia tidak menjadi proksi pelayar anda, ia tidak menyimpan dalam cache laman yang anda lawati melalui terowong, dan ia tidak melihat trafik dalaman melainkan seseorang sengaja mengkonfigurasi pemeriksaan. Terowong yang dibukanya adalah legap kepadanya mengikut reka bentuk.

Ini juga bermakna proksi tidak boleh membaiki pelayan yang tiada pendengar yang sepadan. Kebenaran untuk mencapai destinasi dan perkhidmatan yang mendengar pada destinasi itu ialah dua fakta berasingan, dan hanya yang pertama milik pentadbir proksi.

Pengangkut mesti TCP pada kedua-dua hujung

Proksi CONNECT lazim hanya menyampaikan aliran bait , jadi klien mesti menggunakan pengangkutan aliran. Serpihan klien untuk kes itu kelihatan seperti ini:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

Bahagian pelayan memerlukan pendengar TCP sebenar pada port yang dinamakan dalam baris remote. Menukar proto udp kepada proto tcp-client dalam profil mencipta klien yang menjangka aliran; ia tidak mencipta aliran di sebelah sana. Jika pelayan yang sama juga menjawab melalui UDP pada port itu, itu pendengar lain, bukan mod kedua bagi pendengar yang sama.

Di mana ada instans TCP berasingan, peranti terowong, kolam alamat dan penghalaannya ialah sumber tersendiri. Menyalin konfigurasi yang berfungsi dan mengubah perkataan pengangkutan membiarkan sumber itu terus menunjuk kepada instans asal, yang menghasilkan sambungan yang mengesahkan diri dan kemudian tidak menghalakan apa-apa.

Baca balasan proksi sebelum keputusan VPN

Pertukaran pertama klien ialah baris permintaan yang menamakan hos dan port destinasi. Balasan kepada baris itu memberitahu anda sama ada aliran bait wujud, dan ia tiba sebelum sebarang sijil atau kelayakan diperiksa:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Balasan kelas 200 kepada CONNECT bermaksud aliran itu wujud. Ia tidak mengatakan apa-apa tentang sama ada sijil gerbang dipercayai, sama ada kunci kongsi sepadan, atau sama ada akaun pengguna sah. Pemeriksaan itu berlaku selepas itu, di dalam aliran, dan ia gagal dengan mesej klien sendiri dan bukannya baris status HTTP. Baca log klien untuk peristiwa OpenVPN pertama selepas jabat tangan proksi, bukan baris terakhir sebelum tetingkap ditutup.

Kelayakan proksi dan kelayakan VPN selalunya identiti berbeza yang dipegang oleh pasukan berbeza. 407 bukan kata laluan salah pada akaun VPN, dan sijil yang ditolak bukan masalah kebenaran proksi.

Apa yang CONNECT tidak dedahkan

Terowong CONNECT eksplisit bukan penyadapan. Proksi menyampaikan bait dan tidak menamatkan sesi TLS VPN, jadi pengesahan sijil pelayan oleh klien kekal bermakna dan harus kekal hidup. Mematikan pengesahan untuk melepasi proksi menyelesaikan masalah yang berbeza daripada masalah anda.

Terdapat susunan berasingan di mana organisasi menamatkan dan memeriksa TLS dengan sengaja. Itu memerlukan konfigurasi kepercayaan sendiri dan keputusan dasar sendiri, dan ia bukan apa yang diminta oleh baris http-proxy biasa.

Kos TCP di dalam TCP

Membawa terowong melalui TCP mengekalkan aliran luar teratur dan dihantar semula, dan trafik dalaman biasanya juga TCP. Kedua-dua mekanisme pemulihan tidak menyelaras, jadi satu segmen hilang boleh menghentikan semua yang berkongsi aliran luar itu sehingga ia dihantar semula. Itu pertukaran sebenar demi keserasian, bukan peningkatan percuma.

Gunakan laluan proksi apabila rangkaian tidak meninggalkan alternatif, dan utamakan laluan UDP terus di tempat dasar mengizinkannya. Walau apa pun, selepas perubahan pastikan proksi, destinasi dan profil yang sama mencapai peringkat seterusnya; pelayar yang memuatkan halaman di alamat itu menjalankan protokol lain dan tidak membuktikan apa-apa tentang terowong.