DS-Lite memblokir hosting IPv4 masuk, bukan VPN keluar
Status terjemahan mengikuti sisi yang memulai koneksi. Ikuti permintaan keluar melalui B4 dan AFTR, lalu lihat mengapa hosting justru gagal.
DS-Lite adalah cara memberi pelanggan konektivitas IPv4 melalui jaringan akses yang hanya membawa IPv6. Router rumah tidak punya alamat IPv4 publik khusus sendiri, dan satu fakta itu meyakinkan orang bahwa VPN IPv4 tidak bisa berjalan dari koneksi tersebut. Ke arah keluar, biasanya berjalan baik. Koneksi diterjemahkan oleh penyedia, dan ujung jauh melihat klien IPv4 biasa. Yang rusak adalah arah sebaliknya: menghosting sesuatu yang mengharapkan IPv4 masuk tanpa diminta. Bedanya adalah sisi mana yang memulai percakapan.
Sisi mana yang memulai koneksi
Klien yang memulai koneksi menciptakan status terjemahan sambil berjalan. Penerjemah penyedia melihat paket pertama, mengalokasikan pemetaan, dan meneruskannya. Lalu lintas balasan cocok dengan pemetaan itu karena pemetaan sudah ada.
Server yang menunggu koneksi tidak punya status seperti itu untuk dibuat. Seseorang dari luar harus mencapai alamat dan porta yang belum disetujui penyedia untuk dipetakan, dan itu permintaan yang sama sekali berbeda.
Ikuti permintaan keluar
Arsitektur dalam RFC 6333 menyebut kedua ujung. Elemen di sisi pelanggan adalah B4, yang membungkus IPv4 di dalam IPv6. Elemen di sisi penyedia adalah AFTR, yang melakukan penerjemahan alamat dan meneruskan paket sebagai IPv4.
Client's IPv4 VPN packet
→ Customer B4
→ IPv4 carried over the provider's IPv6 network
→ AFTR address translation
→ IPv4 VPN server
Server VPN menerima koneksi IPv4 normal dari alamat hasil terjemahan penyedia. Ia tidak membutuhkan mode DS-Lite, porta khusus, atau kesadaran bahwa jaringan akses pelanggan hanya IPv6. Itulah bagian yang dilewatkan orang: ujung jauh tidak bisa mengetahuinya.
Konfigurasi klien sendiri sama biasanyanya. Ia membutuhkan jalur IPv4 yang berfungsi ke server, yang disediakan B4 dan AFTR, dan ia membutuhkan nama host server untuk diselesaikan menjadi alamat IPv4.
Mengapa hosting masuk adalah kasus yang gagal
Menjalankan server VPN IPv4 di rumah adalah rancangan yang bertabrakan dengan pengalamatan bersama penyedia. Penerjemah penyedia memiliki alamat publik dan tabel pemetaan, dan ia tidak punya alasan membuat pemetaan masuk permanen untuk satu pelanggan.
Aturan penerusan porta di router rumah tidak dapat mengonfigurasi AFTR. Aturan itu nyata dan benar di perangkat lokal, dan tidak mengubah apa pun di hulu, karena itulah gejalanya tampak seperti masalah firewall yang tidak mau hilang.
Di sinilah penerjemahan tingkat operator berbeda dari satu alamat publik: bahkan penerusan lokal yang benar dapat mendarat di alamat yang dipakai bersama banyak pelanggan.
Diagnosis sebelum mengubah paket akses
Konfirmasikan dulu mode yang disediakan. Tumpukan ganda asli, DS-Lite, dan jaringan hanya-IPv6 yang memakai mekanisme terjemahan lain adalah tiga susunan berbeda, dan nama pemasaran penyedia tidak selalu cocok dengan yang teknis.
Lalu tetapkan empat pengamatan untuk kegagalan keluar. Apakah klien menyelesaikan nama host VPN ke tujuan IPv4? Apakah konektivitas IPv4 biasa berfungsi, bukan permintaan peramban yang mungkin diam-diam memakai IPv6? Transport dan porta apa yang dicoba klien, dan apakah log titik akhir melihat percobaan itu sama sekali? Apakah kegagalan terjadi saat pertukaran awal, setelah periode menganggur, atau hanya pada transfer lebih besar?
Keempat jawaban itu menunjuk ke penyaringan, kedaluwarsa status terjemahan, titik akhir yang salah, atau penanganan ukuran paket. Tidak satu pun terbukti dengan melihat DS-Lite di halaman akun.
Baca perubahan penyedia dengan cermat
Perubahan akun bisa bertepatan dengan koneksi yang berfungsi sambil mengubah beberapa properti sekaligus. Catat properti mana yang berubah, karena nama paket baru bukan penjelasan teknis.
Instruksi untuk mengaktifkan tumpukan ganda bersifat ambigu sampai seseorang mengonfirmasi apa yang sebenarnya disediakan penyedia. Memperlakukannya sebagai persyaratan universal bagi klien VPN IPv4 mengubah dugaan menjadi kebijakan.
Jika persyaratan sebenarnya adalah hosting IPv4 masuk, bicarakan dengan penyedia tentang susunan masuk yang didukung, pengalamatan asli, atau rancangan akses lain. Jika persyaratannya adalah laptop yang mencapai server jarak jauh, tanyakan sebagai gantinya tentang aliran keluar yang tepat itu. Urutan kerja: sebutkan arahnya, konfirmasikan mode yang disediakan, uji IPv4 biasa dan satu transport, lalu ubah paket akses hanya jika arahnya memang menuntut.