OpenVPN terowongan penuh: tambahkan jalan keluar internet di sisi server

Seorang klien melakukan autentikasi, menerima alamat dari kumpulan, dan menjangkau layanan di host VPN, namun setiap tujuan publik berakhir dengan timeout. Beginilah tampilan terowongan tanpa jalan keluar, dan keadaannya tetap begitu sampai empat hal terpisah terpenuhi. Klien harus menerima rute default, server harus meneruskan, firewall harus mengizinkan transit, dan balasan membutuhkan jalur kembali ke kumpulan. Keempat kegagalan berbagi satu gejala, jadi ubah satu item per percobaan dan catat hasilnya.

Dorong rute default dan pastikan apa yang dipasang klien

Baris di sisi server pendek, dan hanya memengaruhi klien yang menerima opsi yang didorong. Bentuk def1 memasang dua setengah-rute default alih-alih menghapus default yang ada, yang menjaga koneksi saat ini tetap hidup sekaligus menangkap setiap tujuan.

push "redirect-gateway def1"

Setelah menghubungkan ulang, baca tabel perutean klien alih-alih memercayai profil. Di Linux kedua entri /1 muncul di samping default asli, dan Windows menampilkan pasangan yang sama sebagai 0.0.0.0/1 dan 128.0.0.0/1. Klien yang mengabaikan opsi yang didorong, atau yang dikonfigurasi untuk menolaknya, mempertahankan default lamanya dan tidak pernah mengirim lalu lintas internet ke dalam terowongan. Selesaikan pertanyaan itu sebelum mengubah apa pun di server, karena tidak ada aturan di sisi server yang bisa mengimbanginya.

Penerusan adalah pengaturan server, bukan pengaturan VPN

Baca flag penerusan sebelum menyentuh perutean. Nilai nol di sana berarti kernel menerima paket klien dan menolak meneruskannya, yang terlihat persis seperti blokir firewall dari ujung jauh. Tetapkan nilainya melalui direktori konfigurasi sistem agar bertahan setelah reboot.

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

Selanjutnya, pastikan host itu sendiri memiliki rute yang berfungsi ke jalan keluar internet. Permintaan dari shell server membuktikan jalur hulu dapat digunakan dan sama sekali tidak mengatakan apa pun tentang meneruskan paket klien, jadi perlakukan keduanya sebagai dua pengujian terpisah. Jika server tidak dapat mencapai tujuan, sebanyak apa pun konfigurasi penerusan tidak akan membantu.

Izinkan tepat transit yang Anda maksud, dan tidak yang lain

Paket yang diteruskan melewati jalur forward; lalu lintas yang dialamatkan ke host VPN itu sendiri melewati input. Keduanya keputusan yang berbeda, dan membuka jalur input tidak mengizinkan transit melalui mesin. Mencampuradukkannya adalah alasan paling umum sebuah firewall tampak mengizinkan segalanya sementara klien masih kehabisan waktu.

Kebijakan minimal menerima koneksi baru dari kumpulan menuju antarmuka keluar dan menerima balasan yang termasuk aliran yang sudah terbentuk. Letakkan di pemilik kumpulan aturan yang dipakai distribusi Anda, alih-alih menambahkan aturan duplikat pada setiap boot; aturan duplikat menumpuk dan penghitungnya berhenti berarti apa pun.

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

Mengalihkan setiap rantai ke terima membuat pengujian lolos dan menghapus alasan firewall itu ada. Jaga cakupan pada kumpulan dan antarmuka keluar, dan biarkan penerusan yang tidak terkait.

Beri balasan tempat untuk pergi

Alamat kumpulan bersifat privat, jadi server publik tidak dapat mengirimkan balasan langsung ke sana. Entah host VPN menerjemahkan alamat sumber saat keluar, atau perangkat di hulu memegang rute kembali ke kumpulan.

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

Tambahkan tepat satu lapisan penerjemahan. NAT kedua lebih jauh di hulu menyembunyikan yang pertama dan membuat kedua log hampir tidak berguna ketika sesuatu rusak nanti. Jika router di hulu sudah merutekan kumpulan kembali, menambahkan penerjemahan di host menjadi mubazir, dan jalur kembali kemudian bergantung pada konfigurasi router itu, bukan konfigurasi Anda.

Instans cloud menambahkan satu gerbang lagi, karena sebagian platform membuang paket yang alamat sumbernya bukan milik instans kecuali pemeriksaan itu dilonggarkan. Pengaturan itu berada di luar tamu dan mudah terlupakan ketika mesin uji lokal berfungsi.

Buktikan dari klien, bukan dari shell server

Mulai dengan permintaan IPv4 numerik, lalu pencarian nama, lalu aplikasinya. Ping membuktikan penerusan dan penerjemahan;itu tidak membuktikan apa pun tentang resolusi, karena opsi DNS baru berlaku ketika integrasi klien memasangnya.

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

Catat perubahan dan langkah pembatalannya sambil berjalan, agar kebijakan keluar dapat dikembalikan dalam satu tindakan ketika pengujian gagal. Resep ini hanya mencakup IPv4; inventarisasi IPv6 secara terpisah sebelum mengklaim penerapan membawa semua lalu lintas.