Awalan awam melalui OpenVPN: baiki laluan pulangan

Lihat terowong naik dan klien mengeping sisi jauh, kemudian alamat awam yang terletak di belakang VPN menjawab dari tempat lain, atau tidak menjawab langsung. Gejala itu biasanya tiada kaitan dengan sifer atau sijil. Awalan yang dihalakan oleh penyedia dihantar sebagai laluan IP, dan membawanya melalui OpenVPN bermakna menghasilkan semula laluan itu pada dua peringkat dan mengekalkan alamat sumber pada laluan pulangan. Menjambatani WAN tidak diperlukan, dan menambah alamat pada antara muka tidak mencipta laluan huluan.

Awalan mesti dihalakan kepada anda dahulu

Tanya penyedia bagaimana blok itu dihantar. Awalan yang dihalakan ke alamat utama pelayan anda berbeza daripada alamat yang penyedia jangka dapat dicapai terus pada segmen WAN. Hanya model pertama berfungsi dengan reka bentuk di sini.

Jika penyedia menghalakan 198.51.100.64/28 ke pelayan masuk anda, paket untuk julat itu tiba di pelayan dan berhenti di situ melainkan anda memajukannya. Jika penyedia sebaliknya menjambatani julat itu ke pautan naik anda, pelayan mesti menjawab ARP untuknya, yang merupakan masalah lain.

Uji model penghantaran sebelum menyentuh OpenVPN: dari luar, ping alamat dalam blok itu dan lihat antara muka mana yang menerimanya. Jika tiada apa-apa tiba, sebarang konfigurasi terowong tidak akan membantu. Jika alamat itu menjawab terus pada WAN, penyedia menjambatani dan bukan menghalakan, dan reka bentuk di bawah tidak terpakai.

Dua peringkat penghalakan: laluan kernel dan iroute

OpenVPN memerlukan awalan di dua tempat. Kernel mesti tahu bahawa awalan itu milik peranti terowong, supaya paket yang dimajukan masuk ke OpenVPN dan bukan laluan lalai. OpenVPN juga mesti tahu klien disahkan mana yang memiliki awalan itu, dan itulah entri iroute dalam direktori khusus klien.

Laluan di sebelah pelayan kelihatan seperti ini, dengan awalan dan topeng sepadan dengan peruntukan:

ip route add 198.51.100.64/28 dev tun0

Konfigurasi khusus klien memberikan pemilikan. Letakkan dalam fail CCD yang dinamakan sempena nama biasa sijil klien, dan pastikan direktori itu yang benar-benar dibaca oleh pelayan:

iroute 198.51.100.64 255.255.255.240

Dokumentasi OpenVPN tentang rangkaian yang dihalakan menerangkan kedua-dua peringkat dan mengapa ia berasingan. Laluan kernel tanpa iroute menghantar paket ke terowong tanpa pemilik, dan OpenVPN membuangnya. iroute tanpa laluan kernel membiarkan paket pada laluan lalai pelayan. Kedua-dua kesilapan kelihatan seperti terowong rosak dari sisi klien.

Di mana alamat perkhidmatan tinggal

Awalan yang diwakilkan bukan sama dengan alamat terowong itu sendiri. Nomborkan pautan dari ruang persendirian jika mahu, dan letakkan alamat perkhidmatan awam di tempat perkhidmatan itu benar-benar berjalan.

Pada klien Linux yang menamatkan perkhidmatan secara setempat, satu alamat hos sudah cukup:

ip address add 198.51.100.70/32 dev lo

Jika awalan dihalakan lebih jauh ke hos VM atau LAN lain, konfigurasikan laluan hiliran itu dan laluan pulangannya sebagai gantinya. Menetapkan setiap alamat dalam blok itu kepada klien VPN tidak diperlukan dan menimbulkan konflik kemudian.

Kekalkan sumber awam pada laluan pulangan

Balasan daripada awalan yang diwakilkan mesti keluar melalui terowong dan sampai ke laluan penyedia. Jika hos jauh menghantarnya melalui ISP sendiri, alamat sumber kelihatan dipalsukan, dan penyedia atau destinasi membuangnya. Penyelesaiannya ialah peraturan berasaskan sumber atau jadual penghalakan khusus, bukan NAT yang lebih luas. Tanpanya, perkhidmatan berfungsi dari rakan terowong dan gagal dari mana-mana tempat lain.

Di pelayan masuk, peraturan masquerade yang luas ialah punca biasa. Ia menulis semula sumber awam ke alamat utama pelayan, dan klien tidak pernah melihat yang sebenar:

iptables -t nat -S POSTROUTING

Hadkan NAT kepada klien VPN persendirian yang memerlukannya dan biarkan awalan yang diwakilkan tidak diterjemah. Kemudian pastikan pelayan memajukan awalan itu sama sekali, kerana rantaian pemajuan dengan penafian lalai membuangnya secara senyap.

Sahkan kedua-dua arah sebelum mempercayainya

Pengesahan ialah empat pemerhatian, bukan satu. Pastikan laluan penyedia tiba, kernel menghantar awalan ke terowong, OpenVPN mengaitkannya dengan klien yang betul, dan balasan kembali dengan sumber awam utuh. Setiap pemerhatian mempunyai arahan sendiri, jadi kegagalan menunjuk kepada satu lapisan dan bukan seluruh reka bentuk. Jalankan semuanya dalam susunan itu selepas setiap perubahan konfigurasi.

Tanya kernel laluan mana yang diambil oleh alamat yang diwakilkan, dan perhatikan terowong semasa permintaan berjalan:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Penapisan laluan songsang boleh membatalkan laluan yang betul. Periksa tetapan berkesan pada terowong dan pada pautan naik, dan ingat bahawa mod ketat menolak trafik yang sumbernya tidak sepadan dengan antara muka tempat ia tiba:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Akhir sekali, uji kes kegagalan. Hentikan terowong dan pastikan awalan awam tidak bocor melalui pautan naik biasa. Memulihkan VPN sepatutnya mengembalikan perkhidmatan tanpa meluaskan port mana yang didedahkan oleh hos.