pfSense sebagai pelayan dan klien VPN: dua laluan, satu penghala

Satu peranti boleh menghadap dua arah serentak: pengguna berayun menyambung masuk, dan kotak yang sama menyambung keluar ke penyedia keluar supaya trafik terpilih keluar melalui rangkaian lain. Mengaktifkan kedua-dua perkhidmatan mengambil masa beberapa minit; membiarkan keduanya hidup bersama memerlukan reka bentuk, kerana peranan kedua menulis semula jadual penghalaan yang menjadi sandaran peranan pertama. Tiga syarat menentukan sama ada susunan ini berjaya, iaitu sama ada perkhidmatan masuk mengekalkan laluan pulangnya sendiri, sama ada terowong keluar masih mencapai pasangannya, dan sama ada trafik yang hendak anda teruskan dipilih untuk keluar. Salah satu silap dan anda mendapat dua terowong yang kedua-duanya melaporkan bersambung sementara tiada apa berguna melintas antaranya. Pemeriksaan di bawah menetapkan setiap syarat mengikut susunan kegagalan biasanya muncul.

Namakan kedua-dua peranan sebelum menyentuh sebarang tetapan

Catat empat fakta bagi setiap instans: pasangan jauhnya, bahan pengesahannya, kolam alamat yang diagihkannya, dan rangkaian di belakangnya. Kedua-dua instans ialah objek berasingan pada peranti dan patut kekal berasingan dalam nota anda juga. Hampir setiap simptom mengelirukan kemudiannya datang daripada nilai keduanya bercampur, dan dua instans yang berkongsi satu set nota ialah cara kolam yang salah berakhir dalam medan yang salah.

Perkhidmatan masuk memerlukan rangkaian terowong yang tidak bertindih dengan alamat terowong keluar atau mana-mana rangkaian persendirian yang dihalakan peranti. Pertindihan ialah satu-satunya kesilapan yang menghasilkan simptom pada kedua-dua peranan serentak, dan jauh lebih murah menangkapnya di atas kertas. Bandingkan kedua-dua kolam dan setiap rangkaian persendirian yang dihalakan di satu tempat sebelum mengkonfigurasi mana-mana perkhidmatan.

Perkakasan dikongsi tidak bermakna kelayakan dikongsi, dan sijil klien daripada kolam akses jauh tidak sepatutnya boleh digunakan terhadap penyedia keluar. Bahan berasingan juga menjadikan pembatalan keputusan setempat dan bukan peristiwa seluruh armada.

Kekalkan balasan pelayan pada laluan WAN

Balasan yang dijana peranti sendiri ialah mangsa pertama laluan lalai yang cuai. Apabila paket terbungkus pengguna berayun tiba, balasan itu trafik yang berasal dari setempat dan mesti keluar melalui antara muka tempat pengguna itu masuk. Jika klien keluar memasang laluan lalai yang menangkapnya, balasan masuk ke terowong yang salah dan sesi tersekat sementara perkhidmatan masih kelihatan sihat.

Tiada satu kotak semak yang menyelesaikannya, kerana keputusan itu tentang trafik mana yang boleh ditangkap klien keluar. Sama ada anda tidak menarik sebarang laluan dan hanya mengarahkan yang anda pilih, atau menarik laluan dan menambah pengecualian yang memastikan perkhidmatan peranti itu sendiri berjalan. Tulis pilihan itu di sebelah instans, atau orang seterusnya akan menganggap yang sebaliknya.

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

Baca jadual penghalaan mengikut padanan terpanjang, bukan mengikut susunan anda mengkonfigurasi sesuatu. Persoalannya ialah entri mana yang menang untuk alamat pasangan keluar dan entri mana yang menang untuk balasan perkhidmatan masuk, dan kedua-dua jawapan itu boleh berbeza.

Jangan biarkan terowong keluar memakan titik hujungnya sendiri

Klien keluar mesti mencapai alamat awam pasangannya untuk membentuk terowong itu sendiri. Jika alamat itu sendiri dihalakan ke dalam terowong, klien mengejar ekornya sendiri: pengangkutan tidak pernah naik, atau naik lalu jatuh pada saat laluan dipasang. Log kelihatan seperti tamat masa pengesahan dan bukan kerosakan penghalaan, sebab itulah laluan wajar diperiksa dahulu.

Periksa laluan sebelum kelayakan dan sekali lagi setelah terowong naik, kerana entri boleh betul semasa but dan salah seminit kemudian. Alamat pasangan mesti menunjuk ke laluan WAN biasa, jangan sekali-kali ke peranti terowong. Setelah pengangkutan stabil, soalan menarik beralih kepada trafik yang diteruskan, iaitu keputusan seterusnya.

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

Pilih pengguna mana yang mendapat laluan keluar

Dasar sumber terletak di pintu masuk tempat trafik masuk ke peranti, jadi pilih kolam akses jauh, atau identiti lebih sempit di dalamnya. Kekalkan destinasi persendirian dan pengecualian pengurusan yang tidak boleh dihantar ke keluar, dan letakkan peraturan itu sebelum peraturan luas. Laluan keluar kemudian memerlukan terjemahan sendiri atau susunan pulang yang dihalakan, yang bagi kebanyakan reka bentuk bermakna NAT keluar pada antara muka keluar yang meliputi kolam itu. Terjemahan tidak memilih jalan keluar; ia hanya menulis semula apa yang sudah keluar, jadi peraturan NAT pada WAN tidak berkaitan tidak mengubah apa-apa dalam pemilihan.

Sahkan hujung jauh membenarkan trafik diteruskan daripada reka bentuk ini, kerana sesetengah penyedia membenarkan dan sesetengah tidak. Perbezaannya kelihatan sebagai terowong yang bersambung dan tidak membawa apa-apa, yang mudah dibaca sebagai kerosakan setempat. Uji ketiga-tiga aliran secara berasingan, kerana ia gagal secara bebas dan dua daripada tiga ialah reka bentuk separuh siap.

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

Perintah pertama ialah sambungan luar pengguna berayun, dan ia berfungsi apabila klien melaporkan urutan permulaan selesai. Yang kedua, dijalankan daripada komputer riba yang bersambung itu, sepatutnya melaporkan alamat penyedia keluar dan bukan alamat WAN anda. Yang ketiga berjalan pada peranti terikat kepada alamat daripada kolam, dan ia menguji dasar sumber untuk trafik yang diteruskan tanpa melibatkan pengguna jauh sama sekali. Jika ia menjawab dari WAN, dasar tidak sepadan, dan sebanyak mana pun penyuntingan NAT tidak membaiki masalah pemilihan.

Putuskan apa yang berlaku apabila laluan keluar gagal

Tulis tingkah laku kegagalan sebelum ia berlaku: apabila terowong keluar jatuh, adakah pengguna kembali ke WAN biasa atau disekat sehingga laluan keluar kembali? Kedua-dua jawapan boleh dipertahankan, dan peranti tidak akan memilih untuk anda. Laluan yang dibuang atau dasar yang menunjuk ke gerbang mati tidak menghasilkan keputusan tersekat sepenuhnya secara automatik. Jika anda mahu sekatan, dasar mesti menyatakannya secara jelas, dan ia mesti diuji dengan membuang laluan keluar dan bukan dengan memikirkannya. Jika anda mahu undur, umumkan kepada pengguna, kerana trafik yang senyap mengambil laluan biasa itulah trafik yang seseorang sangka sudah dilindungi.

Lumpuhkan instans klien, perhatikan apa yang masih boleh dicapai pengguna bersambung, kemudian mulakannya semula. Permintaan yang tamat masa ialah keputusan tersekat sepenuhnya yang anda minta; yang menjawab dengan alamat WAN ialah undur yang anda tidak dokumentasikan. Ulangi pemeriksaan untuk IPv6 dan DNS, kerana dasar yang ditulis untuk IPv4 tidak mengatakan apa-apa tentang trafik AAAA dan penyelesai yang ditolak oleh mana-mana terowong menjawab dari tempat pertanyaan 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

Resipi Netgate untuk OpenVPN yang dihalakan menunjukkan bagaimana dasar sumber, penetapan antara muka dan terjemahan keluar saling sesuai, dan skop tapak-ke-tapak itu ialah bahagian yang tidak patut disalin sepenuhnya. Apa yang ia tidak akan beritahu anda ialah syarat mana antara tiga di atas yang sudah dilanggar oleh reka bentuk anda sendiri.