Koneksi hanya IPv6, layanan IPv4: biarkan proxy SOCKS menjembataninya

Anda tidak perlu alamat dari keluarga tujuan untuk mencapainya, asalkan ada sesuatu di jalur yang bersedia meneruskan. Aplikasi terhubung ke proxy, dan proxy membuka koneksi kedua ke tujuan. Itu dua soket dengan keluarga alamat yang independen, dan tidak ada dalam kedua protokol yang mengharuskan keduanya cocok. Ini penerusan tingkat aplikasi, bukan jalur IPv4 asli, dan perbedaan itulah yang menentukan apa yang akan berhasil dan apa yang tidak. Mencampuradukkan keduanya adalah cara sebuah laptop akhirnya digambarkan memiliki konektivitas IPv4 padahal semua yang dimilikinya hanyalah proxy.

Dua soket, dua keluarga alamat

Permintaan SOCKS5 menamai tujuan dalam salah satu dari tiga bentuk: alamat v4 literal, alamat v6 literal, atau nama untuk diresolusi oleh proxy. Permintaan itu menjelaskan ke mana proxy harus terhubung, bukan bagaimana koneksi klien-ke-proxy terlihat.

Bacalah jenis alamat itu sebagai tiga pilihan independen dalam satu pesan. Proxy yang dapat dijangkau melalui IPv6 dapat membuka soket tujuan IPv4 setiap kali memiliki egress IPv4 yang berfungsi dan kebijakannya mengizinkan permintaan. Spesifikasi SOCKS5 mendefinisikannya tanpa merujuk sama sekali pada transport klien.

Contoh SSH yang terkendali

Ambil host SSH yang Anda berwenang gunakan, yang menjawab di IPv6 dan sendiri dapat menjangkau layanan HTTPS yang hanya ada di v4. Penerusan dinamis OpenSSH menaruh pendengar SOCKS lokal di mesin Anda sementara sesi login berjalan melalui v6.

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

Host dan akun di atas adalah contoh, dan pengikatan loopback menjaga pendengar di komputer ini. Jangan menggantinya dengan pengikatan wildcard agar sebuah kantor dapat berbagi proxy tanpa autentikasi. ExitOnForwardFailure=yes ada agar penerusan yang gagal mengakhiri sesi alih-alih meninggalkan perintah diam-diam berjalan di latar belakang.

Dengan sesi berjalan, permintaannya terlihat seperti ini:

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

Koneksi loopback bukan jalur internet IPv4. Yang meninggalkan mesin Anda adalah sesi login melalui v6, dan sisi jauh itulah yang membuka soket tujuan. Bentuk socks5h juga mendelegasikan resolusi nama ke sisi itu, yang penting ketika klien tidak memiliki jalur resolver IPv4 sendiri.

Apa yang sebenarnya dilihat tujuan

Tujuan melihat alamat egress penerus. Tidak ada alamat milik laptop Anda yang muncul di sana. Daftar izin sumber pada layanan itu harus menamai penerus. Log-nya juga akan mengaitkan lalu lintas dengan penerus. Tuliskan itu dalam catatan perubahan sebelum audit, karena daftar izin yang dibangun di sekitar alamat klien gagal pada permintaan pertama.

Penerus juga tempat kedua belah pihak percakapan terlihat, yang merupakan sifat berguna saat diagnosis dan beban jika penerus dibagikan tanpa kebijakan.

Ini bukan DNS64 atau NAT64

DNS64 menjawab dengan catatan tersintesis yang menggantikan tujuan v4, dan NAT64 menulis ulang paket di sepanjang jalur yang dikonfigurasi. Keduanya tidak menjelaskan apa yang terjadi di sini, di mana satu percakapan transport berakhir dan yang lain dimulai dan tidak ada alamat tersintesis yang menjelaskan hasilnya. Karena itu permintaan yang berhasil tidak mengatakan apa pun tentang layanan terjemahan apa yang dijalankan penyedia Anda, dan proxy dapat menjalankan NAT biasa pada egress-nya sendiri.

Kedua mekanisme dapat ada di jaringan yang sama, jadi jelaskan yang benar-benar Anda verifikasi, bukan yang terdengar paling dekat.

Ketahui cakupannya sebelum menjanjikannya

Penerusan dinamis OpenSSH membawa koneksi TCP, bukan lalu lintas IP sembarangan, jadi UDP, ICMP, dan protokol apa pun yang mengabaikan proxy memerlukan rancangan lain yang didukung. Pertahankan verifikasi kunci host SSH, batasan penerusan server, dan validasi sertifikat HTTPS, karena proxy adalah peserta tepercaya tambahan, bukan alasan untuk melemahkan pemeriksaan identitas. Jika tujuannya membawa transport luar VPN melalui proxy, verifikasi bahwa kedua ujung mendukung transport itu alih-alih menganggap pendengar SOCKS mana pun dapat meneruskannya.

Tidak ada dari ini yang membuat klien menjadi tumpukan ganda, dan tidak ada yang perlu. Ini membuat satu aplikasi mencapai satu layanan melalui satu penerus, yang merupakan klaim lebih kecil dan jauh lebih mudah diverifikasi.