Handshake PiVPN berhasil, halaman macet: periksa MASQUERADE

Ponsel Anda menampilkan tunnel sebagai tersambung, klien melaporkan alamat privat, dan halaman pertama tetap menggantung di tengah pemuatan. Kombinasi itu mengirim sebagian besar orang ke pengaturan cipher dan suhu CPU, tempat sebenarnya tidak ada yang salah. Tunnel sudah naik, jadi negosiasi selesai; yang gagal adalah langkah setelahnya, ketika server mencoba menyerahkan paket klien ke internet. Ikuti jalur yang sama dengan paket-paket itu, dan ketidakcocokan biasanya terlihat di satu baris tabel NAT.

Mulai dari apa yang bisa dan tidak bisa dijangkau klien

Dari klien yang tersambung, muat halaman yang berada di internet publik dan catat apakah gagal seketika atau macet di tengah. Lalu buka sumber daya di alamat privat server VPN itu sendiri dan bandingkan kedua hasilnya.

Alamat tunnel yang menjawab ping sementara situs publik kehabisan waktu adalah tanda masalah penerusan atau penerjemahan, bukan handshake yang rusak. Panel status milik klien sendiri tidak bisa membedakan keduanya, karena panel itu hanya tahu kanal kendali sudah naik. Periksa antarmuka tunnel di server dengan ip -br addr show tun0 dan pastikan alamat yang diberikan ke klien berada di dalam kumpulan alamat yang Anda konfigurasikan. Jika kumpulan dan alamat klien tidak cocok, perbaiki itu lebih dulu, karena setiap aturan di bawah ini mencocokkan kumpulan tersebut.

Selanjutnya, tanyakan kepada server antarmuka mana yang akan dipakainya untuk mencapai alamat publik. ip route get 203.0.113.9 mencetak perangkat dan sumber yang dipilih pada baris pertamanya. Catat nama perangkat itu, karena itulah nilai yang harus ada di aturan NAT.

Baca aturan yang menentukan apakah paket keluar

MASQUERADE menulis ulang paket hanya ketika paket keluar melalui antarmuka yang disebut dalam aturan. Aturan yang dibatasi pada perangkat kabel tidak melakukan apa pun untuk lalu lintas yang keluar lewat Wi-Fi, dan paket mempertahankan alamat sumber privatnya sampai ke router hulu. Router itu tidak punya rute kembali ke kumpulan tunnel Anda, jadi ia membuang balasannya, dan klien melihat koneksi yang terbuka lalu mati. Gejalanya membesar seiring banyaknya halaman yang tiba sebelum balasan pertama dibutuhkan.

Daftarkan tabel yang hidup dan baca kolom antarmuka keluar alih-alih hanya mencari kata MASQUERADE. Keluaran bentuk tambah lebih mudah dibandingkan daripada daftar yang diformat:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Pada Raspberry Pi yang dulu memakai Ethernet dan kini memakai Wi-Fi, nama lama hampir selalu menjadi seluruh ceritanya. Pemasang mencatat perangkat mana yang ada saat penyiapan, dan kumpulan aturan tersimpan memutar ulangnya pada setiap boot. Bandingkan perangkat dari pencarian rute dengan perangkat di aturan sebelum mengubah hal lain. Jika keduanya cocok, antarmuka bukan masalah Anda dan Anda harus beralih ke penghitung di bagian terakhir. Jika berbeda, perbaikannya adalah suntingan satu kata di berkas persistensi.

Perbaiki kumpulan aturan tersimpan, bukan hanya yang sedang berjalan

Menyunting tabel yang hidup saja bertahan sampai reboot berikutnya, yang justru cukup lama untuk meyakinkan Anda bahwa masalahnya sudah beres. Aturan yang kembali saat boot tinggal di berkas yang dimuat ulang oleh paket persistensi firewall. Pada image Pi berbasis Debian, berkas itu biasanya /etc/iptables/rules.v4.

Ambil salinan sebelum menyentuhnya, lalu ganti antarmuka keluar pada baris MASQUERADE dengan perangkat yang Anda catat, misalnya -o wlan0 alih-alih -o eth0. Biarkan rentang sumber apa adanya, kecuali kumpulan klien Anda berubah. Muat ulang dan pastikan aturan kini menyebut perangkat yang benar:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dua pengaturan yang bersebelahan mudah dilupakan. sysctl net.ipv4.ip_forward harus melaporkan 1, dan router hulu tidak boleh menyaring alamat sumber privat sendiri.

Buktikan aturannya menyala, lalu pisahkan apa yang masih lambat

Penghitung adalah satu-satunya bukti jujur bahwa sebuah aturan cocok. Jalankan daftar panjang, mulai unduhan di klien, dan jalankan lagi. Kolom paket dan byte di samping aturan Anda seharusnya naik, dan aturan yang tetap nol masih belum cocok. Jika penghitung bergerak tetapi halaman masih gagal, bandingkan rentang sumber dengan kumpulan sebenarnya memakai grep -n "^server " /etc/openvpn/server.conf. Jika bergerak dan halaman termuat tetapi throughput buruk, penerjemahan sudah beres dan masalah yang tersisa ada di tempat lain.

Bandingkan dua transfer dari klien yang sama, satu ke host di jaringan lokal dan satu melalui tunnel ke host yang sama. Lambat pada keduanya menunjuk ke tautan hulu atau sambungan Wi-Fi Pi, bukan VPN. Lambat hanya melalui tunnel menunjuk ke MTU dan pengiriman ulang, yang bisa Anda periksa dengan ip -s link show tun0 sebelum mengubah pengaturan kripto apa pun.

Untuk membatalkan percobaan, pulihkan salinan dan muat ulang, lalu pastikan aturan asli dan penghitungnya kembali. Tulis perangkat keluar dan perintah muat ulang ke catatan server, karena perubahan tautan hulu berikutnya akan menemukan ketidakcocokan yang sama lagi. Aturan yang menyebut perangkat salah tetap tak terlihat sampai lalu lintas membutuhkannya.