OpenVPN terowong penuh: tambah jalan keluar internet di sebelah pelayan

Seorang klien mengesahkan dirinya, menerima alamat daripada kolam dan mencapai perkhidmatan pada hos VPN, namun setiap destinasi awam tamat dengan tamat masa. Beginilah rupa terowong tanpa jalan keluar, dan ia kekal begitu sehingga empat perkara berasingan menjadi benar. Klien mesti menerima laluan lalai, pelayan mesti memajukan, tembok api mesti membenarkan lintasan, dan balasan memerlukan laluan balik ke kolam. Keempat-empat kegagalan berkongsi satu simptom, jadi ubah satu item bagi setiap percubaan dan catat hasilnya.

Tolak laluan lalai dan sahkan apa yang klien pasang

Baris di sebelah pelayan adalah pendek, dan ia hanya menjejaskan klien yang menerima pilihan yang ditolak. Bentuk def1 memasang dua separuh laluan lalai dan bukannya memadam laluan lalai sedia ada, yang mengekalkan sambungan semasa hidup sambil masih menangkap setiap destinasi.

push "redirect-gateway def1"

Selepas menyambung semula, baca jadual penghalaan klien daripada mempercayai profil. Pada Linux dua entri /1 muncul di sebelah laluan lalai asal, dan Windows menunjukkan pasangan yang sama sebagai 0.0.0.0/1 dan 128.0.0.0/1. Klien yang mengabaikan pilihan yang ditolak, atau yang dikonfigurasikan untuk menolaknya, mengekalkan laluan lalai lamanya dan tidak pernah menghantar trafik internet ke dalam terowong. Selesaikan persoalan itu sebelum mengubah apa-apa pada pelayan, kerana tiada peraturan di sebelah pelayan boleh mengimbanginya.

Pemajuan ialah tetapan pelayan, bukan tetapan VPN

Baca bendera pemajuan sebelum menyentuh penghalaan. Sifar di situ bermakna kernel menerima paket klien dan enggan memajukannya, yang kelihatan tepat seperti sekatan tembok api dari hujung jauh. Tetapkan nilainya melalui direktori konfigurasi sistem supaya ia kekal selepas but semula.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Seterusnya, sahkan bahawa hos itu sendiri mempunyai laluan yang berfungsi ke jalan keluar internet. Permintaan daripada shell pelayan membuktikan laluan huluan boleh digunakan dan tidak mengatakan apa-apa langsung tentang memajukan paket klien, jadi anggap kedua-duanya sebagai dua ujian berasingan. Jika pelayan tidak dapat mencapai destinasi, sebanyak mana pun konfigurasi pemajuan tidak akan membantu.

Benarkan lintasan yang anda maksudkan, dan tidak yang lain

Paket yang dimajukan melintasi laluan forward; trafik yang dialamatkan kepada hos VPN itu sendiri melintasi input. Ini keputusan yang berbeza, dan membuka laluan input tidak membenarkan lintasan melalui mesin. Mencampuradukkannya ialah sebab paling biasa tembok api kelihatan membenarkan segala-galanya sedangkan klien masih tamat masa.

Dasar minimum menerima sambungan baharu daripada kolam ke arah antara muka keluar dan menerima balasan yang tergolong dalam aliran yang telah ditetapkan. Letakkannya pada pemilik set peraturan yang digunakan oleh pengedaran anda, dan bukannya menambah peraturan pendua pada setiap but; peraturan pendua terkumpul dan pembilang tidak lagi bermakna apa-apa.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Menukar setiap rantaian kepada terima membuat ujian lulus dan menghapuskan sebab tembok api wujud. Kekalkan skop pada kolam dan antara muka keluar, dan biarkan pemajuan tidak berkaitan.

Beri balasan tempat untuk pergi

Alamat kolam adalah peribadi, jadi pelayan awam tidak boleh menyampaikan balasan terus kepadanya. Sama ada hos VPN menterjemah alamat sumber semasa keluar, atau peranti di huluan memegang laluan balik ke kolam.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Tambah tepat satu lapisan terjemahan. NAT kedua lebih jauh di huluan menyembunyikan yang pertama dan menjadikan kedua-dua log hampir tidak berguna apabila sesuatu rosak kemudian. Jika penghala di huluan sudah menghalakan kolam kembali, menambah terjemahan pada hos adalah berlebihan, dan laluan balik kemudian bergantung pada konfigurasi penghala itu dan bukan konfigurasi anda.

Contoh awan menambah satu lagi pintu, kerana sesetengah platform menggugurkan paket yang alamat sumbernya bukan milik contoh itu melainkan semakan itu dilembutkan. Tetapan itu berada di luar tetamu dan mudah dilupakan apabila mesin ujian tempatan berfungsi.

Buktikan daripada klien, bukan daripada shell pelayan

Mulakan dengan permintaan IPv4 berangka, kemudian carian nama, kemudian aplikasi. ping membuktikan pemajuan dan terjemahan;ia tidak membuktikan apa-apa tentang penyelesaian nama, kerana pilihan DNS hanya berkuat kuasa apabila integrasi klien memasangnya.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Catat perubahan dan langkah pembatalan sambil anda berjalan, supaya dasar keluar boleh dikembalikan dalam satu tindakan apabila ujian gagal. Resipi ini hanya merangkumi IPv4; inventori IPv6 secara berasingan sebelum mendakwa penggunaan membawa semua trafik.