pfSense sebagai server dan klien VPN: dua jalur, satu router

Satu perangkat dapat menghadap dua arah sekaligus: pengguna keliling terhubung masuk, dan kotak yang sama terhubung keluar ke penyedia keluar agar lalu lintas terpilih keluar melalui jaringan lain. Mengaktifkan kedua layanan hanya butuh menit; membuat keduanya hidup berdampingan menuntut rancangan, karena peran kedua menulis ulang tabel perutean yang menjadi sandaran peran pertama. Tiga syarat menentukan apakah susunan ini berhasil, yaitu apakah layanan masuk mempertahankan jalur pulangnya sendiri, apakah terowongan keluar masih dapat mencapai rekannya, dan apakah lalu lintas yang hendak Anda teruskan terpilih untuk keluar. Salah satu saja keliru, Anda mendapat dua terowongan yang keduanya melaporkan tersambung sementara tidak ada yang berguna melintas di antaranya. Pemeriksaan di bawah menetapkan tiap syarat sesuai urutan munculnya kegagalan biasanya.

Beri nama kedua peran sebelum menyentuh satu pengaturan

Tuliskan empat fakta untuk tiap instans: rekannya yang jauh, materi autentikasinya, kumpulan alamat yang dibagikannya, dan jaringan di belakangnya. Kedua instans adalah objek terpisah pada perangkat dan seharusnya tetap terpisah di catatan Anda juga. Hampir setiap gejala membingungkan nantinya berasal dari tercampurnya nilai keduanya, dan dua instans yang berbagi satu set catatan adalah cara kumpulan yang salah berakhir di kolom yang salah.

Layanan masuk memerlukan jaringan terowongan yang tidak bertumpang-tindih dengan alamat terowongan keluar atau jaringan privat mana pun yang dirutekan perangkat. Tumpang tindih adalah satu-satunya kesalahan yang memunculkan gejala di kedua peran sekaligus, dan jauh lebih murah menangkapnya di atas kertas. Bandingkan kedua kumpulan dan setiap jaringan privat yang dirutekan di satu tempat sebelum mengonfigurasi salah satu layanan.

Perangkat keras bersama tidak berarti kredensial bersama, dan sertifikat klien dari kumpulan akses jauh seharusnya tidak dapat dipakai terhadap penyedia keluar. Materi terpisah juga mengubah pencabutan menjadi keputusan lokal alih-alih peristiwa seluruh armada.

Pertahankan balasan server di jalur WAN

Balasan yang dihasilkan perangkat sendiri adalah korban pertama rute bawaan yang ceroboh. Saat paket terbungkus dari pengguna keliling tiba, balasannya adalah lalu lintas yang berasal dari lokal dan harus keluar melalui antarmuka tempat pengguna itu masuk. Jika klien keluar memasang rute bawaan yang menangkapnya, balasan masuk ke terowongan yang salah dan sesi tersendat sementara layanan masih tampak sehat.

Tidak ada satu kotak centang yang menyelesaikan ini, karena keputusannya menyangkut lalu lintas mana yang boleh ditangkap klien keluar. Entah Anda tidak menarik rute apa pun dan hanya mengarahkan yang Anda pilih, atau menarik rute lalu menambahkan pengecualian yang menjaga layanan perangkat itu sendiri tetap jalan. Tuliskan pilihan itu di samping instans, atau orang berikutnya akan menganggap yang sebaliknya.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Baca tabel perutean menurut kecocokan terpanjang, bukan menurut urutan Anda mengonfigurasi sesuatu. Pertanyaannya adalah entri mana yang menang untuk alamat rekan keluar dan entri mana yang menang untuk balasan layanan masuk, dan kedua jawaban itu bisa berbeda.

Jangan biarkan terowongan keluar memakan titik ujungnya sendiri

Klien keluar harus mencapai alamat publik rekannya agar terowongan terbentuk sama sekali. Jika alamat itu sendiri dirutekan ke dalam terowongan, klien mengejar ekornya sendiri: transportasi tidak pernah naik, atau naik lalu jatuh pada saat rute dipasang. Log terlihat seperti batas waktu autentikasi, bukan kesalahan perutean, karena itulah rute perlu diperiksa lebih dulu.

Periksa rute sebelum kredensial dan sekali lagi setelah terowongan naik, karena entri bisa benar saat boot dan salah semenit kemudian. Alamat rekan harus menunjuk ke jalur WAN biasa, jangan pernah ke perangkat terowongan. Begitu transportasi stabil, pertanyaan menarik berpindah ke lalu lintas yang diteruskan, yaitu keputusan berikutnya.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Pilih pengguna mana yang mendapat jalur keluar

Kebijakan sumber berada di pintu masuk tempat lalu lintas masuk ke perangkat, jadi pilih kumpulan akses jauh, atau identitas yang lebih sempit di dalamnya. Pertahankan tujuan privat dan pengecualian pengelolaan yang tidak boleh pernah dikirim ke jalur keluar, dan letakkan aturan itu sebelum aturan lebar. Jalur keluar lalu memerlukan penerjemahan sendiri atau susunan pulang yang dirutekan, yang pada sebagian besar rancangan berarti NAT keluar pada antarmuka keluar yang mencakup kumpulan itu. Penerjemahan tidak memilih jalan keluar; ia hanya menulis ulang apa yang sudah pergi, jadi aturan NAT pada WAN yang tak berkaitan tidak mengubah apa pun dalam pemilihan.

Pastikan ujung jauh mengizinkan lalu lintas diteruskan dari rancangan ini, karena sebagian penyedia mengizinkan dan sebagian tidak. Perbedaannya tampak sebagai terowongan yang tersambung dan tidak membawa apa pun, yang mudah dibaca keliru sebagai kesalahan lokal. Uji ketiga aliran secara terpisah, karena mereka gagal secara mandiri dan dua dari tiga berarti rancangan setengah jadi.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Perintah pertama adalah koneksi luar pengguna keliling, dan ia bekerja saat klien melaporkan urutan inisialisasi selesai. Yang kedua, dijalankan dari laptop yang tersambung itu, seharusnya melaporkan alamat penyedia keluar alih-alih alamat WAN Anda. Yang ketiga berjalan di perangkat terikat ke alamat dari kumpulan, dan ia menguji kebijakan sumber untuk lalu lintas diteruskan tanpa melibatkan pengguna jauh sama sekali. Jika ia menjawab dari WAN, kebijakan tidak cocok, dan sebanyak apa pun penyuntingan NAT tidak memperbaiki masalah pemilihan.

Putuskan apa yang terjadi saat jalur keluar gagal

Tuliskan perilaku kegagalan sebelum terjadi: saat terowongan keluar putus, apakah pengguna kembali ke WAN biasa atau diblokir sampai jalur keluar kembali? Kedua jawaban dapat dipertahankan, dan perangkat tidak akan memilih untuk Anda. Rute yang dihapus atau kebijakan yang menunjuk gateway mati tidak otomatis menghasilkan hasil terblokir sepenuhnya. Jika Anda ingin pemblokiran, kebijakan harus menyatakannya secara eksplisit, dan harus diuji dengan mencabut jalur keluar alih-alih memikirkannya. Jika Anda ingin fallback, umumkan itu kepada pengguna, karena lalu lintas yang diam-diam mengambil jalur biasa justru lalu lintas yang dianggap seseorang sudah tercakup.

Nonaktifkan instans klien, amati apa yang masih dapat dijangkau pengguna tersambung, lalu jalankan lagi. Permintaan yang habis waktu adalah hasil terblokir sepenuhnya yang Anda minta; yang menjawab dengan alamat WAN adalah fallback yang tidak Anda dokumentasikan. Ulangi pemeriksaan untuk IPv6 dan DNS, karena kebijakan yang ditulis untuk IPv4 tidak mengatakan apa pun tentang lalu lintas AAAA dan resolver yang didorong salah satu terowongan menjawab dari tempat kueri benar-benar keluar.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Resep Netgate untuk OpenVPN yang dirutekan menunjukkan bagaimana kebijakan sumber, penetapan antarmuka, dan penerjemahan keluar saling cocok, dan cakupan situs-ke-situsnya adalah bagian yang tidak boleh disalin seluruhnya. Yang tidak akan diberitahukannya adalah syarat mana dari tiga di atas yang sudah dilanggar rancangan Anda sendiri.