DS-Lite menyekat hosting IPv4 masuk, bukan VPN keluar

Keadaan terjemahan mengikut pihak yang memulakan sambungan. Ikuti permintaan keluar melalui B4 dan AFTR, kemudian lihat mengapa hosting gagal.

DS-Lite ialah cara memberi pelanggan kesambungan IPv4 melalui rangkaian akses yang hanya membawa IPv6. Penghala rumah tidak mempunyai alamat IPv4 awam khusus sendiri, dan satu fakta itu meyakinkan orang bahawa VPN IPv4 tidak boleh berfungsi dari sambungan itu. Ke arah keluar, ia biasanya berfungsi dengan baik. Sambungan diterjemahkan oleh penyedia, dan hujung jauh melihat klien IPv4 biasa. Yang rosak ialah arah bertentangan: menghoskan sesuatu yang menjangka IPv4 masuk tanpa diminta. Bezanya ialah pihak mana yang memulakan perbualan.

Pihak mana yang memulakan sambungan

Klien yang memulakan sambungan mencipta keadaan terjemahan sambil bergerak. Penterjemah penyedia melihat paket pertama, memperuntukkan pemetaan dan memajukannya. Trafik balasan sepadan dengan pemetaan itu kerana pemetaan sudah wujud.

Pelayan yang menunggu sambungan tidak mempunyai keadaan sebegitu untuk dicipta. Seseorang dari luar perlu mencapai alamat dan port yang penyedia tidak bersetuju untuk dipetakan, dan itu permintaan yang sama sekali berbeza.

Ikuti permintaan keluar

Seni bina dalam RFC 6333 menamakan kedua-dua hujung. Elemen di pihak pelanggan ialah B4, yang merangkumi IPv4 dalam IPv6. Elemen di pihak penyedia ialah AFTR, yang melakukan terjemahan alamat dan memajukan paket sebagai IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

Pelayan VPN menerima sambungan IPv4 biasa dari alamat terjemahan penyedia. Ia tidak memerlukan mod DS-Lite, port khas atau pengetahuan bahawa rangkaian akses pelanggan hanya IPv6. Itulah bahagian yang orang terlepas pandang: hujung jauh tidak dapat mengetahuinya.

Konfigurasi klien itu sendiri juga biasa. Ia memerlukan laluan IPv4 yang berfungsi ke pelayan, yang disediakan B4 dan AFTR, dan ia memerlukan nama hos pelayan diselesaikan kepada alamat IPv4.

Mengapa hosting masuk ialah kes yang gagal

Menjalankan pelayan VPN IPv4 di rumah ialah reka bentuk yang bertembung dengan pengalamatan kongsi penyedia. Penterjemah penyedia memiliki alamat awam dan jadual pemetaan, dan ia tiada sebab untuk mencipta pemetaan masuk kekal bagi seorang pelanggan.

Peraturan pemajuan port pada penghala rumah tidak boleh mengkonfigurasi AFTR. Peraturan itu nyata dan betul pada peranti tempatan, dan ia tidak mengubah apa-apa di hulu, sebab itulah gejalanya kelihatan seperti masalah tembok api yang tidak hilang.

Di sinilah terjemahan peringkat pengendali berbeza daripada satu alamat awam: malah pemajuan tempatan yang betul boleh mendarat pada alamat yang dikongsi banyak pelanggan.

Diagnosis sebelum menukar pelan akses

Sahkan mod yang diperuntukkan dahulu. Timbunan berganda asli, DS-Lite dan rangkaian hanya-IPv6 yang menggunakan mekanisme terjemahan lain ialah tiga susunan berbeza, dan nama pemasaran penyedia tidak selalu sepadan dengan yang teknikal.

Kemudian tetapkan empat pemerhatian untuk kegagalan keluar. Adakah klien menyelesaikan nama hos VPN kepada destinasi IPv4? Adakah kesambungan IPv4 biasa berfungsi, bukannya permintaan pelayar yang mungkin senyap-senyap menggunakan IPv6? Pengangkutan dan port apa yang dicuba klien, dan adakah log titik akhir melihat percubaan itu langsung? Adakah kegagalan berlaku semasa pertukaran awal, selepas tempoh melahu, atau hanya pada pemindahan lebih besar?

Keempat-empat jawapan itu menunjuk kepada penapisan, luput keadaan terjemahan, titik akhir yang salah atau pengendalian saiz paket. Tiada satu pun daripadanya dibuktikan dengan melihat DS-Lite di halaman akaun.

Baca perubahan penyedia dengan teliti

Perubahan akaun boleh bertepatan dengan sambungan yang berfungsi sambil mengubah beberapa sifat sekali gus. Catat sifat mana yang berubah, kerana nama pakej baharu bukan penjelasan teknikal.

Arahan untuk mengaktifkan timbunan berganda adalah kabur sehingga seseorang mengesahkan apa yang sebenarnya diperuntukkan penyedia. Menganggapnya sebagai keperluan sejagat bagi klien VPN IPv4 menjadikan tekaan sebagai dasar.

Jika keperluan sebenar ialah hosting IPv4 masuk, bincangkan dengan penyedia tentang susunan masuk yang disokong, pengalamatan asli atau reka bentuk akses lain. Jika keperluannya ialah komputer riba yang mencapai pelayan jauh, tanyalah sebaliknya tentang aliran keluar yang tepat itu. Urutan kerja: namakan arah, sahkan mod yang diperuntukkan, uji IPv4 biasa dan satu pengangkutan, kemudian tukar pelan akses hanya jika arah itu benar-benar memerlukannya.

Artikel berkaitan