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 3128

Sisi 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 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

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.

Artikel terkait