Proksi SOCKS5 untuk OpenVPN: terowong TCP atau memproksi aplikasi?

Rangkaian yang hanya membenarkan keluar melalui proksi ialah tempat profil yang berfungsi tiba-tiba mati. Alamat proksi ialah pemboleh ubah paling kurang menarik dalam kegagalan itu. Segala-galanya ditentukan oleh bentuk trafik yang akan disampaikan oleh proksi, kerana proksi ini menghantar aliran bait dan terowong UDP bukan begitu. Itu meninggalkan dua seni bina, dan kedua-duanya pecah di tempat berbeza.

Satu kekangan menentukan reka bentuk

SOCKS5 memang menetapkan mod persatuan UDP. Namun sokongan proksi klien OpenVPN dibina di sekitar aliran: socks-proxy didokumenkan untuk profil TCP, dan proksi HTTP CONNECT tidak mempunyai laluan langsung untuk datagram. Satu baris dokumentasi menyelesaikan seni bina sebelum anda menyentuh fail konfigurasi.

Jadi persoalannya bukan proksi mana yang hendak dipilih. Persoalannya sama ada terowong menjadi aliran, atau kekal sebagai datagram dan membiarkan sesuatu yang lain menyerap pemproksian.

Pilihan A: jadikan terowong sebagai aliran

Ini memerlukan pelayan dengan pendengar TCP, dan profil klien yang menamakan proksi. Kedua-dua bahagian diperlukan, dan bahagian pelayan ialah yang orang lupa:

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

Gantikan baris terakhir dengan http-proxy proxy.internal 8080 apabila proksi bertutur HTTP, dan tambahkan fail kelayakan jika ia memintanya. Proksi mesti bersedia melakukan CONNECT ke port VPN anda, dan pelayan mesti menjawab pada TCP; pendengar hanya UDP mengabaikan percubaan itu. Memilih 443 ialah langkah praktikal, kerana banyak rangkaian ketat membenarkannya dan sedikit perkara lain.

Kosnya ialah TCP bertindan di atas TCP. Satu segmen luar yang hilang menyekat setiap aliran dalam yang berkongsi sambungan itu, jadi pemulihan yang biasanya bebas menjadi dikongsi. Persediaan juga mengambil masa lebih lama, dan laluan luar yang goyah menjadi terowong goyah dan bukan perlahan.

Pilihan B: biarkan terowong itu

Apabila terowong mesti kekal pada UDP, terowong bukan tempat anda mengkonfigurasi apa-apa. Sebaliknya, TCP keluar daripada aplikasi diubah hala ke pendengar SOCKS tempatan, dan aplikasi tidak pernah tahu bahawa proksi wujud. Di Linux itu biasanya redsocks serta peraturan NAT REDIRECT dalam jadual nat.

TCP sahaja, sekali lagi. Proksi hanya HTTP seperti privoxy tidak boleh menyampaikan protokol sewenang-wenangnya, dan reka bentuk ini juga tidak menambah sokongan datagram untuk aplikasi.

Memberitahu setiap aplikasi tentang proksi secara langsung biasanya lebih baik di tempat perisian menyokongnya. Lebih mudah diaudit, dan ia gagal di tempat yang benar-benar boleh anda lihat.

Di mana setiap pilihan gagal

Pilihan A gagal apabila pelayan tiada pendengar TCP, apabila proksi menolak sasaran CONNECT, atau apabila aliran luar dihadkan di bawah apa yang diperlukan terowong. Dua yang pertama meninggalkan entri dalam log proksi; yang ketiga meninggalkan sambungan yang terbentuk dan kemudian terasa salah. Baca log itu sebelum menyunting profil, kerana ia memisahkan masalah kebenaran daripada masalah kapasiti. CONNECT yang selesai memindahkan siasatan ke dalam terowong.

Pilihan B gagal untuk apa-apa yang memerlukan datagram, untuk protokol yang tidak difahami proksi, dan secara senyap pada hos di mana peraturan ubah hala wujud tetapi penghalaan menghantar trafik melewatinya.

Tiada pilihan mengubah keperluan peranti. Paket masih memerlukan nod TUN atau TAP sebelum kernel menghalakannya, jadi proses itu masih memerlukan kebenaran pada /dev/net/tun. Pembalut mengubah apa yang berlaku selepas nod itu dibuka, bukan sama ada anda memerlukannya.

Buktikan laluan mana yang anda bina

Lihat soket dan bukan ikon dulang. Proses VPN sepatutnya memegang sambungan yang terbentuk ke alamat proksi, dan proksi sepatutnya telah mencatat sasaran yang diminta untuk dicapai:

ss -tnp | grep openvpn

Kemudian tuju destinasi yang hanya boleh dilayan terowong, dan nama yang hanya boleh dijawab oleh penyelesai terowong. Sambungan proksi yang selesai dengan terowong mati biasanya bermaksud hujung jauh tidak pernah menawarkan pengangkutan yang dinamakan dalam profil anda.

Catat pengangkutan dan proksi yang menerima di tempat yang tahan lama. Apabila profil yang sama gagal pada rangkaian lain, catatan itu menyingkirkan atau mengesahkan proksi dalam beberapa saat.