Sambungan IPv6 sahaja, perkhidmatan IPv4: biarkan proksi SOCKS menjambatani

Anda tidak memerlukan alamat daripada keluarga destinasi untuk mencapainya, selagi ada sesuatu di laluan yang sanggup menghantar semula. Aplikasi bersambung ke proksi, dan proksi membuka sambungan kedua ke destinasi. Itu dua soket dengan keluarga alamat yang bebas, dan tiada apa dalam mana-mana protokol yang memerlukan kedua-duanya sepadan. Ini penghantaran semula di peringkat aplikasi, bukan laluan IPv4 asli, dan perbezaan itulah yang menentukan apa yang akan berfungsi dan apa yang tidak. Mengelirukan kedua-duanya ialah cara komputer riba akhirnya digambarkan mempunyai konektiviti IPv4 sedangkan semua yang dimilikinya ialah proksi.

Dua soket, dua keluarga alamat

Permintaan SOCKS5 menamakan destinasi dalam salah satu daripada tiga bentuk: alamat v4 literal, alamat v6 literal, atau nama untuk proksi selesaikan. Permintaan itu menerangkan ke mana proksi harus bersambung, bukan bagaimana sambungan klien-ke-proksi kelihatan.

Baca jenis alamat itu sebagai tiga pilihan bebas dalam satu mesej. Proksi yang boleh dicapai melalui IPv6 boleh membuka soket destinasi IPv4 apabila ia mempunyai egress IPv4 yang berfungsi dan dasarnya membenarkan permintaan itu. Spesifikasi SOCKS5 mentakrifkannya tanpa sebarang rujukan kepada pengangkutan klien.

Contoh SSH terkawal

Ambil hos SSH yang anda dibenarkan gunakan, yang menjawab melalui IPv6 dan sendiri boleh mencapai perkhidmatan HTTPS yang hanya wujud pada v4. Penghantaran dinamik OpenSSH meletakkan pendengar SOCKS tempatan pada mesin anda sementara sesi log masuk berjalan melalui v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Hos dan akaun di atas ialah contoh, dan pengikatan loopback mengekalkan pendengar pada komputer ini. Jangan gantikannya dengan pengikatan wildcard supaya pejabat boleh berkongsi proksi tanpa pengesahan. ExitOnForwardFailure=yes wujud supaya penghantaran yang gagal menamatkan sesi dan bukannya meninggalkan arahan senyap berjalan di latar belakang.

Dengan sesi berjalan, permintaan kelihatan seperti ini:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Sambungan loopback bukan laluan internet IPv4. Apa yang meninggalkan mesin anda ialah sesi log masuk melalui v6, dan bahagian jauh itulah yang membuka soket destinasi. Bentuk socks5h juga menyerahkan resolusi nama kepada bahagian itu, yang penting apabila klien tiada laluan penyelesai IPv4 sendiri.

Apa yang sebenarnya dilihat destinasi

Destinasi melihat alamat keluar penghantar. Tiada alamat milik komputer riba anda muncul di situ. Senarai benarkan sumber pada perkhidmatan itu mesti menamakan penghantar. Lognya juga akan mengaitkan trafik dengan penghantar. Tuliskan itu dalam rekod perubahan sebelum audit, kerana senarai benarkan yang dibina di sekitar alamat klien gagal pada permintaan pertama.

Penghantar juga tempat kedua-dua bahagian perbualan kelihatan, iaitu sifat berguna semasa diagnosis dan beban jika penghantar dikongsi tanpa dasar.

Ini bukan DNS64 atau NAT64

DNS64 menjawab dengan rekod sintesis yang menggantikan destinasi v4, dan NAT64 menulis semula paket di sepanjang laluan yang dikonfigurasikan. Kedua-duanya tidak menerangkan apa yang berlaku di sini, di mana satu perbualan pengangkutan berakhir dan satu lagi bermula dan tiada alamat sintesis menjelaskan hasilnya. Permintaan yang berjaya oleh itu tidak berkata apa-apa tentang perkhidmatan terjemahan yang dikendalikan pembekal anda, dan proksi mungkin menjalankan NAT biasa pada egressnya sendiri.

Kedua-dua mekanisme boleh wujud dalam rangkaian yang sama, jadi terangkan yang benar-benar anda sahkan, bukan yang kedengaran paling dekat.

Ketahui skop sebelum menjanjikannya

Penghantaran dinamik OpenSSH membawa sambungan TCP, bukan trafik IP sewenang-wenangnya, jadi UDP, ICMP dan mana-mana protokol yang mengabaikan proksi memerlukan reka bentuk lain yang disokong. Kekalkan pengesahan kunci hos SSH, sekatan penghantaran pelayan dan pengesahan sijil HTTPS, kerana proksi ialah peserta dipercayai tambahan, bukan alasan untuk melemahkan pemeriksaan identiti. Jika matlamatnya ialah membawa pengangkutan luar VPN melalui proksi, sahkan bahawa kedua-dua hujung menyokong pengangkutan itu dan bukannya menganggap mana-mana pendengar SOCKS boleh menghantarnya semula.

Tiada satu pun daripada ini menjadikan klien dua-stack, dan tiada satu pun daripadanya perlu. Ia menjadikan satu aplikasi mencapai satu perkhidmatan melalui satu penghantar, yang merupakan dakwaan lebih kecil dan jauh lebih mudah disahkan.