NAT di Server VPN atau di Router? Keduanya Bisa Berfungsi

Menandai koneksi sebagai rute default di laptop adalah langkah yang semua orang ingat, dan justru itulah yang tidak mengubah apa pun di gateway. Klien kini mengirim permintaan internet ke dalam terowongan; apakah permintaan itu keluar dari gedung bergantung pada penerusan, titik penerjemahan, dan jalur balik yang mencapai alamat privat klien. Dua susunan dapat menyediakan ketiganya, keduanya menaruh pekerjaan di tempat berbeda, dan keduanya gagal dengan cara sunyi yang sama ketika tidak ada yang memiliki arah balasan. Memilih di antara keduanya adalah pertanyaan tentang siapa yang seharusnya melihat kumpulan klien.

Mitos: rute klien membangun jalan keluar

Tunneling paksa adalah kebijakan sisi klien: ia memutuskan bahwa lalu lintas masuk ke adaptor VPN, bukan ke adaptor fisik. Dokumentasi perutean VPN Microsoft menjelaskan pemisahan dan perilaku paksa itu, dan itu adalah pernyataan tentang tabel rute klien, bukan tentang aturan penerusan server. Dari sudut pandang klien, terowongan adalah tempat internet tinggal; dari sudut pandang gateway, sebuah paket datang dari alamat yang tidak pernah didengar siapa pun di atasnya. Tidak ada pihak yang salah konfigurasi sendiri, dan itulah sebabnya kegagalan tampak seperti server rusak bagi orang di depan laptop.

Ketidakcocokan itulah seluruh masalah yang dipecahkan sisa artikel ini. Sesuatu harus membuat alamat privat klien dapat dikembalikan, dan pilihannya adalah di mana.

Gambar jalur balasan lebih dulu

Tuliskan jalur itu dengan alamat nyata sebelum menyentuh pengaturan apa pun, dan tandai dua titik penerjemahan calon di atasnya. Lab ini menggunakan kumpulan VPN 10.70.0.0/24 dengan satu klien di 10.70.0.37, alamat LAN server 172.16.40.10, router di 172.16.40.1, dan jalan keluar publik 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?)

Server yang sudah menjelajahi internet hanya membuktikan jalurnya sendiri. Paket yang diteruskan atas nama klien adalah keputusan berbeda, diambil oleh kebijakan penerusan di mesin yang sama, dan itulah yang biasanya hilang. Menandai tiga titik keputusan pada diagram menjaga percakapan tentang salah satunya pada satu waktu.

Opsi A: terjemahkan di server VPN

Di sini server menerjemahkan sumber klien ke alamat LAN-nya sendiri sebelum menyerahkan paket ke router, dan router menerapkan penerjemahan biasanya saat keluar. Pada balasan, pemetaan router memulihkan alamat server dan pemetaan server memulihkan alamat klien. Dua penerjemahan stateful secara berurutan normal dan dapat dijalankan, asalkan keduanya dicatat; router tidak pernah memerlukan rute ke kumpulan, dan itulah daya tarik susunan ini.

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

Gunakan pembacaan ini untuk melihat apa yang sudah dimiliki server alih-alih menganggap NAT ada. Aturan masquerade Linux yang disalin dari blog bukan konfigurasi Windows, dan izin di firewall host untuk pendengar VPN bukan kebijakan yang sama dengan izin meneruskan permintaan klien lebih jauh. Konfirmasi peran penerusan server dari antarmuka manajemennya sendiri, lalu lihat penerjemahan secara terpisah, karena keduanya sering diaktifkan oleh bagian penerapan yang berbeda.

Opsi B: bawa kumpulan ke router

Pada susunan kedua server meneruskan alamat sumber asli klien, dan router menerjemahkannya. Itu menjaga kumpulan klien tetap terlihat di tepi, yang membantu jika router adalah tempat kebijakan lalu lintas, pencatatan, atau inspeksi berada. Itu juga berarti router memerlukan rute balik untuk 10.70.0.0/24 yang menunjuk ke 172.16.40.10, ditambah kebijakan internet yang benar-benar menyertakan prefiks itu; aturan yang ditulis untuk subnet LAN tidak secara diam-diam meluas ke kumpulan.

Pilih ini ketika perangkat tepi adalah pemilik kebijakan yang dimaksud dan dapat menerima prefiks lain di tabel perutean dan penerjemahannya. Pilih penerjemahan di sisi server ketika kumpulan harus tetap tak terlihat di hulu dan router tidak dikelola oleh tim yang sama. Tidak ada opsi yang tersirat oleh kotak centang mana pun di klien, dan tidak ada yang lebih aman secara umum; keduanya menaruh visibilitas dan pemeliharaan di tempat berbeda.

Buat DNS, IPv6, dan penerimaan eksplisit

Penerjemahan alamat tidak memperbaiki resolusi nama. Klien dapat menggunakan resolver yang dikirim bersama profil VPN, resolver privat untuk ruang nama tertentu, atau resolver publik yang disetujui, dan resolver yang tidak dapat dijangkau di bawah kebijakan itu akan terus gagal setelah perutean berfungsi. Uji nama dan alamat secara terpisah agar dua kegagalan itu tidak pernah menyatu dalam satu laporan.

IPv6 memerlukan paragrafnya sendiri dalam desain. Penerjemahan IPv4 yang berfungsi tidak mengatakan apa pun tentang apakah klien IPv6 memiliki rute, sumber publik yang valid, atau kebijakan yang memblokirnya saat terowongan putus. Membiarkan hal itu tidak disebutkan berarti separuh klien diam-diam melewati gateway sementara separuh lainnya berfungsi.

Untuk penerimaan, ikuti satu permintaan klien yang diizinkan dan balasannya melintasi kedua batas, dan catat alamat yang seharusnya dilihat setiap batas pada saat itu. Catatan itulah yang membuat perubahan kumpulan berikutnya menjadi penyuntingan lima menit alih-alih perdebatan tentang siapa yang memiliki rute balik yang hilang. Simpan catatan itu bersama profil klien alih-alih di tiket, karena profil adalah yang pertama ditemukan insinyur berikutnya.