NAT di Pelayan VPN atau di Penghala? Kedua-duanya boleh berfungsi

Menandakan sambungan sebagai laluan lalai pada komputer riba ialah langkah yang semua orang ingat, dan itulah yang tidak mengubah apa-apa pada get laluan. Klien kini menghantar permintaan internet ke dalam terowong; sama ada ia keluar dari bangunan bergantung pada penghantaran ke hadapan, titik penterjemahan dan laluan balik yang sampai ke alamat peribadi klien. Dua susunan boleh menyediakan ketiga-tiganya, ia meletakkan kerja di tempat berbeza, dan kedua-duanya gagal dengan cara senyap yang sama apabila tiada siapa yang memiliki arah balasan. Memilih antara keduanya ialah persoalan siapa yang sepatutnya melihat kolam klien.

Mitos: laluan klien membina jalan keluar

Terowong paksa ialah dasar sebelah klien: ia memutuskan bahawa trafik pergi ke penyesuai VPN bukan penyesuai fizikal. Dokumentasi penghalaan VPN Microsoft menerangkan pemisahan dan tingkah laku paksa itu, dan ia adalah kenyataan tentang jadual laluan klien, bukan tentang peraturan penghantaran pelayan. Dari sudut pandangan klien terowong ialah tempat internet tinggal; dari sudut pandangan get laluan, satu paket tiba dari alamat yang tiada siapa di atasnya pernah mendengar. Tiada pihak salah dikonfigurasi secara bersendirian, dan itulah sebabnya kegagalan kelihatan seperti pelayan rosak kepada orang di hadapan komputer riba.

Ketidakpadanan itulah keseluruhan masalah yang diselesaikan oleh baki artikel ini. Sesuatu mesti menjadikan alamat peribadi klien boleh dipulangkan, dan pilihannya ialah di mana.

Lukis laluan balasan dahulu

Tulis laluan itu dengan alamat sebenar sebelum menyentuh sebarang tetapan, dan tandakan dua titik penterjemahan calon padanya. Makmal ini menggunakan kolam VPN 10.70.0.0/24 dengan satu klien di 10.70.0.37, alamat LAN pelayan 172.16.40.10, penghala di 172.16.40.1 dan jalan keluar awam 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Pelayan yang sudah melayari internet hanya membuktikan laluannya sendiri. Paket yang dihantar ke hadapan bagi pihak klien ialah keputusan berbeza, diambil oleh dasar penghantaran pada mesin yang sama, dan itulah yang biasanya tiada. Menandakan tiga titik keputusan pada rajah mengekalkan perbualan tentang salah satunya pada satu masa.

Pilihan A: terjemah pada pelayan VPN

Di sini pelayan menterjemah sumber klien ke alamat LAN sendiri sebelum menyerahkan paket kepada penghala, dan penghala menggunakan terjemahan biasa semasa keluar. Pada balasan, pemetaan penghala memulihkan alamat pelayan dan pemetaan pelayan memulihkan alamat klien. Dua terjemahan berkeadaan berturut-turut adalah normal dan boleh dilaksanakan, dengan syarat kedua-duanya direkodkan; penghala tidak pernah memerlukan laluan ke kolam, dan itulah tarikan susunan ini.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Gunakan bacaan ini untuk melihat apa yang pelayan sudah ada dan bukannya menganggap NAT ada. Peraturan masquerade Linux yang disalin dari blog bukan konfigurasi Windows, dan kebenaran dalam tembok api hos untuk pendengar VPN bukan dasar yang sama dengan kebenaran menghantar permintaan klien ke hadapan. Sahkan peranan penghantaran pelayan dari antara muka pengurusannya sendiri, kemudian lihat penterjemahan secara berasingan, kerana kedua-duanya sering diaktifkan oleh bahagian penggunaan yang berbeza.

Pilihan B: bawa kolam ke penghala

Dalam susunan kedua pelayan menghantar alamat sumber sebenar klien, dan penghala menterjemahkannya. Itu mengekalkan kolam klien kelihatan di pinggir, yang membantu jika penghala ialah tempat dasar trafik, pengelogan atau pemeriksaan berada. Ia juga bermakna penghala memerlukan laluan balik untuk 10.70.0.0/24 yang menunjuk ke 172.16.40.10, serta dasar internet yang benar-benar merangkumi awalan itu; peraturan yang ditulis untuk subnet LAN tidak merebak secara senyap ke kolam.

Pilih ini apabila peranti pinggir ialah pemilik dasar yang dimaksudkan dan boleh menerima awalan lain dalam jadual penghalaan dan penterjemahannya. Pilih penterjemahan sebelah pelayan apabila kolam harus kekal tidak kelihatan di atas dan penghala tidak ditadbir oleh pasukan yang sama. Tiada pilihan yang tersirat oleh mana-mana kotak semak pada klien, dan tiada yang lebih selamat secara umum; kedua-duanya meletakkan keterlihatan dan penyelenggaraan di tempat berbeza.

Jadikan DNS, IPv6 dan penerimaan jelas

Penterjemahan alamat tidak membaiki penyelesaian nama. Klien boleh menggunakan penyelesai yang disediakan bersama profil VPN, penyelesai peribadi untuk ruang nama tertentu, atau penyelesai awam yang diluluskan, dan penyelesai yang tidak dapat dicapai di bawah dasar itu akan terus gagal selepas penghalaan berfungsi. Uji nama dan alamat secara berasingan supaya dua kegagalan itu tidak pernah bergabung dalam satu laporan.

IPv6 memerlukan perenggannya sendiri dalam reka bentuk. Penterjemahan IPv4 yang berfungsi tidak mengatakan apa-apa tentang sama ada klien IPv6 mempunyai laluan, sumber awam yang sah atau dasar yang menyekatnya apabila terowong jatuh. Membiarkan perkara itu tidak dinyatakan bermakna separuh klien diam-diam memintas get laluan sementara separuh lagi berfungsi.

Untuk penerimaan, ikuti satu permintaan klien yang dibenarkan dan balasannya merentasi kedua-dua sempadan, dan catat alamat yang sepatutnya dilihat oleh setiap sempadan pada masa itu. Catatan itulah yang menjadikan perubahan kolam seterusnya satu suntingan lima minit dan bukannya perdebatan tentang siapa yang memiliki laluan balik yang hilang. Simpan catatan itu bersama profil klien dan bukannya dalam tiket, kerana profil ialah perkara yang akan ditemui jurutera seterusnya dahulu.