Tersambung ke OpenVPN tetapi tidak ada yang termuat: penelusuran dari klien

Jendela klien menampilkan Connected, alamat tunnel ada, dan peramban masih berputar. Kombinasi itu normal, karena jabat tangan yang berhasil hanya membuktikan bahwa tunnel sudah dibangun; itu tidak mengatakan apakah server akan meneruskan paket Anda, menulis ulang sumbernya, atau menjawab kueri DNS Anda. Kesalahan yang paling sering dilakukan adalah membuka konfigurasi server lebih dulu. Sebaliknya, bergeraklah dari klien ke luar, karena setiap langkah di bawah memberi tahu apakah langkah berikutnya bahkan layak diperiksa.

Mulai dari klien dan bergerak ke luar

Jalankan tiga pengujian dalam urutan ini dan catat di mana yang pertama gagal. Ping alamat tunnel server, yang membuktikan bahwa tunnel itu sendiri membawa lalu lintas. Ping alamat publik berdasarkan nomor, yang membuktikan penerusan dan penerjemahan tanpa melibatkan resolusi nama. Lalu coba selesaikan nama host, satu-satunya pengujian yang memakai DNS. Setiap hasil menghapus satu lapisan penuh dari kecurigaan.

Jangan melompat ke pengujian ketiga karena peramban terasa lebih cepat. Pemuatan halaman yang gagal mencakup ketiga lapisan sekaligus, dan dari situlah orang mulai lalu membangun ulang tunnel yang tadinya berfungsi. Halaman yang gagal tidak memberi tahu lapisan mana dari ketiganya yang rusak.

Dua tangkapan menunjukkan di mana paket berhenti

Selagi ping ke alamat publik berjalan dari klien, ambil satu tangkapan di antarmuka tunnel dan satu di uplink yang seharusnya mencapai internet. Jalankan keduanya bersamaan agar tanda waktunya sejajar.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Jika permintaan muncul di tunnel dan tidak pernah di uplink, server membuangnya antara tunnel dan kabel, dan penyebabnya adalah penerusan atau kebijakan firewall penerusan, bukan NAT. Jika muncul di keduanya, server sudah melakukan bagiannya dan jawabannya hilang lebih jauh ke luar, yang mengarah ke penerjemahan, penyaring di hulu, atau pembatasan dari penyedia.

Ambil nama uplink dari tabel routing, bukan dari tutorial. Citra cloud dan adaptor yang diganti namanya jarang cocok dengan antarmuka contoh dalam panduan, dan tangkapan di perangkat yang salah terlihat persis seperti server yang tidak meneruskan:

ip -4 route get 9.9.9.9

Bidang dev pada keluaran itu adalah nama yang nanti dibutuhkan aturan NAT, jadi simpanlah.

Penerusan adalah sakelar kernel dan kebijakan firewall

Kernel harus setuju untuk meneruskan sejak awal. Baca nilai saat ini, lalu jadikan pengaturannya permanen alih-alih hanya menuliskannya ke kernel yang sedang berjalan:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Penerusan hanya separuhnya. Pada host yang memakai UFW, kebijakan penerusan diatur di /etc/default/ufw dan harus ACCEPT sebelum pemuatan ulang berlaku. Penolakan bawaan pada jalur penerusan membuat jabat tangan tetap sehat sepenuhnya sambil membuang diam-diam setiap paket yang mencoba keluar lewat tunnel, dan itulah tepat gejala yang Anda mulai.

Host yang mengelola nftables secara langsung menghadapi pertanyaan yang sama dalam sintaksis lain. Perhatikan penghitung pada rantai penerusan selagi pengujian klien berjalan, karena rantai yang dikonsultasikan dan rantai yang membuang terlihat sama saja dalam berkas konfigurasi.

Namai antarmuka keluar yang sebenarnya dalam aturan NAT

Penerjemahan sumber semestinya berada pada antarmuka yang benar-benar meninggalkan host, dengan kumpulan alamat yang dibagikan server. Kedua belah aturan itu harus menggambarkan kenyataan, dan tidak ada yang opsional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Kegagalan klasik adalah aturan yang disalin dari panduan yang menyebut -o eth0 pada mesin yang adaptornya bernama lain. Aturan itu terpasang tanpa peringatan, tidak cocok dengan apa pun, dan klien tetap tanpa internet. Kumpulan alamat adalah belahan lain dari kesalahan yang sama: jika server membagikan 10.44.0.0/24 dan aturannya mencakup 10.8.0.0/24, tidak akan pernah ada yang cocok.

Perhatikan penghitung alih-alih memercayai teks aturan. Daftar itu melaporkan paket per aturan, dan aturan yang tidak pernah cocok tetap nol seberapa pun benar tampaknya. Beri waktu satu menit lalu lintas klien nyata sebelum membaca apa pun dari angka itu:

iptables -t nat -L POSTROUTING -v -n

Hitungan paket nol setelah pengujian klien nyata berarti pencocokannya salah, bukan tunnelnya rusak. Begitu cocok, simpan kumpulan aturan agar bertahan setelah reboot; perbaikan yang hanya hidup di riwayat shell Anda hilang pada restart pertama.

Jika server juga merupakan instans NAT cloud, platform juga punya suara. Instans yang menerjemahkan alamat biasanya memerlukan pemeriksaan sumber dan tujuan dimatikan di tempat penyedia menyediakan pengaturan itu, dan porta VPN itu sendiri harus dapat dijangkau dari luar.

DNS adalah kegagalan kedua di belakang yang pertama

Ping berdasarkan alamat yang berfungsi sementara nama gagal adalah masalah resolver, dan penyebabnya sendiri. Klien yang mempertahankan resolver lokalnya mengirim kueri itu ke dalam tunnel penuh dan menunggu jawaban yang tidak pernah datang, karena resolver lokal kini berada di sisi rute yang salah.

Dorong resolver dari server agar klien tahu ke mana harus bertanya. Dua entri memberi klien cadangan jika yang pertama tidak terjangkau, dan keduanya sebaiknya resolver yang benar-benar diizinkan tunnel.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Klien Windows kemudian bisa tetap kembali ke resolver lokal, dan itulah yang block-outside-dns ada untuk mencegah, dengan biaya kehilangan nama yang hanya bisa diselesaikan jaringan lokal. Klien Linux dengan systemd-resolved sering mengabaikan resolver yang didorong kecuali skrip memasangnya, jadi periksa resolvectl status untuk perangkat tunnel sebelum menyimpulkan dorongan itu diabaikan.

Selesaikan penelusuran seperti yang dialami pengguna. Muat halaman nyata dari klien, pastikan alamat asal keluarnya, boot ulang server, sambungkan lagi, dan ulangi tiga pengujian. Hanya putaran kedua itulah yang membuktikan aturan tersimpan, kebijakan firewall, dan resolver yang didorong semuanya bertahan bersama.