OpenVPN melalui proxy HTTP: baca dulu balasan CONNECT
Proxy CONNECT meneruskan byte, jadi kedua ujung memerlukan TCP. Baca 407, 403, dan 503 sebelum menyalahkan sertifikat, dan biarkan verifikasi server tetap aktif.
Arahkan klien VPN ke proxy HTTP korporat, dan fakta berguna pertama adalah proxy tidak berbicara protokol VPN. Ia membuka koneksi TCP biasa ke alamat yang Anda sebutkan lalu menyingkir, membiarkan klien dan server melakukan pertukaran mereka sendiri melalui aliran itu. Semua yang dibutuhkan klien, dari jenis transport hingga pendengar server, harus cocok dengan susunan itu. Dua ketidakcocokan menjelaskan sebagian besar kegagalan: profil UDP yang diarahkan ke proxy CONNECT, dan balasan proxy yang disalahartikan sebagai kesalahan VPN.
Apa yang dibawa proxy, dan apa yang tidak
Proxy hanyalah satu lompatan transport. Ia tidak menjadi proxy peramban Anda, tidak menyimpan dalam cache situs yang Anda kunjungi melalui terowongan, dan tidak melihat lalu lintas dalam kecuali seseorang sengaja mengonfigurasi inspeksi. Terowongan yang dibukanya tidak tembus baginya secara desain.
Itu juga berarti proxy tidak dapat memperbaiki server yang tidak memiliki pendengar yang cocok. Izin untuk mencapai tujuan dan layanan yang mendengarkan di tujuan itu adalah dua fakta terpisah, dan hanya yang pertama milik administrator proxy.
Pengangkut harus TCP di kedua ujung
Proxy CONNECT konvensional hanya meneruskan aliran byte , jadi klien harus menggunakan transport aliran. Fragmen klien untuk kasus itu terlihat seperti ini:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Sisi server memerlukan pendengar TCP sungguhan pada port yang disebut di baris remote. Mengubah proto udp menjadi proto tcp-client dalam profil membuat klien yang mengharapkan aliran; itu tidak membuat aliran di sisi lain. Jika server yang sama juga menjawab lewat UDP di port itu, itu pendengar lain, bukan mode kedua dari yang sama.
Di mana ada instans TCP terpisah, perangkat terowongan, kumpulan alamat, dan peruteannya adalah sumber daya tersendiri. Menyalin konfigurasi yang berfungsi dan mengubah kata transport membuat sumber daya itu tetap menunjuk ke instans asli, yang menghasilkan koneksi yang terautentikasi lalu tidak merutekan apa pun.
Baca balasan proxy sebelum hasil VPN
Pertukaran pertama klien adalah baris permintaan yang menyebut hos dan port tujuan. Balasan atas baris itu memberi tahu Anda apakah aliran byte ada sama sekali, dan balasan itu datang sebelum sertifikat atau kredensial apa pun diperiksa:
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 |
Balasan kelas 200 atas CONNECT berarti aliran itu ada. Itu tidak mengatakan apa pun tentang apakah sertifikat gateway tepercaya, apakah kunci bersama cocok, atau apakah akun pengguna valid. Pemeriksaan itu terjadi setelahnya, di dalam aliran, dan gagal dengan pesan klien sendiri alih-alih baris status HTTP. Baca log klien untuk peristiwa OpenVPN pertama setelah jabat tangan proxy, bukan baris terakhir sebelum jendela ditutup.
Kredensial proxy dan kredensial VPN sering merupakan identitas berbeda yang dipegang tim berbeda. 407 bukan kata sandi salah pada akun VPN, dan sertifikat yang ditolak bukan masalah izin proxy.
Apa yang tidak diungkap CONNECT
Terowongan CONNECT eksplisit bukan penyadapan. Proxy meneruskan byte dan tidak mengakhiri sesi TLS milik VPN, jadi verifikasi sertifikat server oleh klien tetap bermakna dan harus tetap aktif. Mematikan verifikasi untuk melewati proxy menyelesaikan masalah yang berbeda dari masalah Anda.
Ada pengaturan terpisah di mana organisasi mengakhiri dan memeriksa TLS dengan sengaja. Itu memerlukan konfigurasi kepercayaan sendiri dan keputusan kebijakan sendiri, dan itu bukan yang diminta baris http-proxy biasa.
Biaya TCP di dalam TCP
Membawa terowongan lewat TCP menjaga aliran luar tetap berurutan dan dikirim ulang, dan lalu lintas dalam biasanya juga TCP. Kedua mekanisme pemulihan tidak berkoordinasi, jadi satu segmen hilang dapat menghentikan semua yang berbagi aliran luar itu sampai dikirim ulang. Itu pertukaran nyata demi kompatibilitas, bukan peningkatan gratis.
Gunakan jalur proxy ketika jaringan tidak meninggalkan alternatif, dan utamakan jalur UDP langsung di tempat kebijakan mengizinkannya. Bagaimanapun, setelah perubahan pastikan proxy, tujuan, dan profil yang sama mencapai tahap berikutnya; peramban yang memuat halaman di alamat itu menjalankan protokol lain dan tidak membuktikan apa pun tentang terowongan.