pfSense OpenVPN: menjangkau jaringan di balik router lain

Laptop Anda menjangkau LAN pfSense melalui VPN dan tetap gagal menjangkau layanan dua hop lebih dalam, dan perbedaannya adalah satu keputusan perutean per pemilik. Tiga perangkat harus sepakat sebelum paket menyelesaikan perjalanan pulang-perginya: klien, firewall, dan router yang benar-benar memiliki jaringan tujuan. Lewatkan salah satunya dan gejalanya terlihat sama.

Ikuti satu paket melalui ketiga keputusan itu sebelum mengubah aturan, karena setiap pemilik memiliki kendali berbeda dan mode kegagalan berbeda.

Satu paket, tiga keputusan perutean

Klien memutuskan apakah tujuan termasuk dalam terowongan, dan hanya dapat memutuskan dari apa yang diketahuinya: rute yang didorong, rute lokal, atau default yang sudah mencakup semuanya. pfSense memutuskan ke mana paket dikirim berikutnya, yang bagi jaringan di balik router lain berarti rute statis melalui gateway yang dapat dijangkau pada antarmuka yang benar. Router di bawah memutuskan apakah ia mengetahui jalur kembali ke kumpulan VPN, dan jika tidak, balasan dibuang atau dikirim ke tempat yang tidak berguna. Setiap keputusan independen dari dua lainnya.

Kegagalan salah satu dari mereka menghasilkan laporan pengguna yang sama. Itulah sebabnya urutan penelusuran kesalahan lebih penting daripada perkakasnya.

Beri klien prefiks, bukan tebakan

Pada server pfSense SSL/TLS dengan jaringan terowongan IPv4 lebih besar dari /30, bidang IPv4 Local network(s) membagikan rute ke klien saat mereka terhubung. Tambahkan prefiks hilir di sana alih-alih mengandalkan klien untuk mengarangnya. Lalu baca tabel sebenarnya klien setelah terhubung, karena profil dengan route-nopull atau filter rute dapat mengabaikan apa yang dikirim server. Server bisa sepenuhnya benar sementara klien tidak memasang apa pun.

Mode server dan topologi lain memiliki batas berbeda, dan kebijakan per klien atau per koneksi dapat mengubah apa yang diterima klien tertentu. Verifikasi pada klien yang penting, bukan pada klien yang kebetulan Anda uji pertama.

Arahkan pfSense ke router internal

Rute statis di pfSense memerlukan gateway yang ditentukan dan dapat dijangkau, dan antarmuka yang dipilih untuk gateway itu harus antarmuka yang benar-benar mencapainya, seperti yang dijelaskan panduan rute statis Netgate. Dalam tata letak ilustratif, tautan transit adalah 192.168.77.1 di firewall dan 192.168.77.2 di router internal, dengan jaringan layanan di 172.16.30.0/25 di belakangnya. Rute kemudian menyebutkan prefiks dan hop berikutnya, bukan alamat layanan. Menggunakan alamat dari jaringan jauh sebagai gateway adalah cara umum membangun rute yang terlihat benar dan tidak meneruskan ke mana pun.

Memberi nama pada antarmuka tidak menjelaskan jaringan di baliknya. Rute statis adalah penjelasan itu.

Sisi jauh harus mengetahui kumpulan

Router di bawah memerlukan rute balik untuk kumpulan, dalam contoh ini 10.55.0.0/24 melalui 192.168.77.1, kecuali rute default atau protokol dinamis sudah menyediakannya. Gateway host layanan itu sendiri harus mengarah ke router tersebut, yang biasanya benar ketika router adalah gateway default-nya dan salah ketika host dikonfigurasi secara manual. Perutean berbasis kebijakan di firewall juga dapat menimpa tabel untuk lalu lintas tertentu, jadi periksa apakah suatu aturan memilih gateway lain sebelum menyimpulkan rute itu salah.

Tidak diperlukan penerjemahan untuk desain ini, dan membiarkan alamat sumber klien terlihat memungkinkan jaringan hilir menerapkan kebijakannya sendiri.

Untuk penerimaan, ikuti satu permintaan baru melalui masuknya terowongan, keluar internal firewall, dan balasan dari tujuan. Jika penerjemahan justru sengaja digunakan, catat sumber yang dilihat jaringan hilir dan bagaimana balasan diharapkan kembali.

Simpan rencana tiga pemilik bersama aplikasi yang diizinkan, agar administrator berikutnya dapat merekonstruksi jalurnya alih-alih menemukannya kembali.