Proxy SOCKS5 untuk OpenVPN: terowongan TCP atau memproksikan aplikasi?

Jaringan yang hanya mengizinkan keluar lewat proxy adalah tempat profil yang berfungsi tiba-tiba mati. Alamat proxy adalah variabel paling tidak menarik dalam kegagalan itu. Semuanya ditentukan oleh bentuk lalu lintas yang akan diteruskan proxy, karena proxy ini mengirim aliran byte dan terowongan UDP bukan itu. Itu menyisakan dua arsitektur, dan keduanya rusak di tempat berbeda.

Satu batasan menentukan rancangan

SOCKS5 memang menetapkan mode asosiasi UDP. Dukungan proxy klien OpenVPN tetap dibangun di sekitar aliran: socks-proxy didokumentasikan untuk profil TCP, dan proxy HTTP CONNECT tidak punya jalur apa pun untuk datagram. Satu baris dokumentasi menentukan arsitektur sebelum Anda menyentuh berkas konfigurasi.

Jadi pertanyaannya bukan proxy mana yang dipilih. Pertanyaannya apakah terowongan menjadi aliran, atau tetap datagram dan membiarkan sesuatu yang lain menyerap pemroksian.

Opsi A: jadikan terowongan sebagai aliran

Ini memerlukan server dengan pendengar TCP, dan profil klien yang menyebut proxy. Kedua bagian diperlukan, dan sisi server adalah yang orang lupakan:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Ganti baris terakhir dengan http-proxy proxy.internal 8080 saat proxy berbicara HTTP, dan tambahkan berkas kredensial jika memintanya. Proxy harus bersedia melakukan CONNECT ke porta VPN Anda, dan server harus menjawab pada TCP; pendengar hanya UDP mengabaikan upaya itu. Memilih 443 adalah langkah praktis, karena banyak jaringan ketat mengizinkannya dan sedikit hal lain.

Biayanya adalah TCP bertumpuk di atas TCP. Satu segmen luar yang hilang menghentikan setiap aliran dalam yang berbagi koneksi itu, sehingga pemulihan yang biasanya independen menjadi bersama. Penyiapan juga memakan waktu lebih lama, dan jalur luar yang goyah menjadi terowongan yang goyah, bukan yang lambat.

Opsi B: biarkan terowongan apa adanya

Ketika terowongan harus tetap di UDP, terowongan bukan tempat Anda mengonfigurasi apa pun. Sebagai gantinya, TCP keluar dari aplikasi dialihkan ke pendengar SOCKS lokal, dan aplikasi tidak pernah tahu bahwa proxy ada. Di Linux itu biasanya redsocks ditambah aturan NAT REDIRECT di tabel nat.

Hanya TCP, lagi. Proxy hanya HTTP seperti privoxy tidak dapat meneruskan protokol sembarang, dan rancangan ini juga tidak menambahkan dukungan datagram untuk aplikasi.

Memberi tahu setiap aplikasi tentang proxy secara langsung biasanya lebih baik di tempat perangkat lunak mendukungnya. Lebih mudah diaudit, dan gagal di tempat yang benar-benar bisa Anda lihat.

Di mana tiap opsi gagal

Opsi A gagal ketika server tidak punya pendengar TCP, ketika proxy menolak target CONNECT, atau ketika aliran luar dibatasi di bawah kebutuhan terowongan. Dua yang pertama meninggalkan entri di log proxy; yang ketiga meninggalkan koneksi yang terbentuk lalu terasa salah. Baca log itu sebelum menyunting profil, karena itu memisahkan masalah izin dari masalah kapasitas. CONNECT yang selesai memindahkan penyelidikan ke dalam terowongan.

Opsi B gagal untuk apa pun yang membutuhkan datagram, untuk protokol yang tidak dipahami proxy, dan diam-diam pada hos tempat aturan pengalihan ada tetapi perutean mengirim lalu lintas melewatinya.

Tidak ada opsi yang mengubah syarat perangkat. Paket tetap membutuhkan simpul TUN atau TAP sebelum kernel merutekannya, jadi prosesnya tetap membutuhkan izin pada /dev/net/tun. Pembungkus mengubah apa yang terjadi setelah simpul itu terbuka, bukan apakah Anda memerlukannya.

Membuktikan jalur mana yang Anda bangun

Lihat soket, bukan ikon baki. Proses VPN seharusnya memegang koneksi yang terbentuk ke alamat proxy, dan proxy seharusnya sudah mencatat target yang diminta untuk dicapai:

ss -tnp | grep openvpn

Lalu tuju tujuan yang hanya bisa dilayani terowongan, dan nama yang hanya bisa dijawab resolver terowongan. Koneksi proxy yang selesai dengan terowongan mati biasanya berarti ujung jauh tidak pernah menawarkan transport yang disebut di profil Anda.

Catat transport dan proxy yang menerima di tempat yang tahan lama. Ketika profil yang sama gagal di jaringan lain, catatan itu menyingkirkan atau menegaskan proxy dalam hitungan detik.