Handshake PiVPN berjaya, halaman tersekat: semak MASQUERADE

Telefon anda menunjukkan terowong sebagai bersambung, klien melaporkan alamat peribadi, dan halaman pertama masih tergantung di tengah pemuatan. Gabungan itu menghantar kebanyakan orang ke tetapan sifer dan suhu CPU, tempat sebenarnya tiada apa yang rosak. Terowong telah naik, jadi rundingan selesai; yang gagal ialah langkah selepas itu, apabila pelayan cuba menyerahkan paket klien kepada internet. Ikut laluan yang sama dengan paket itu, dan ketidakpadanan biasanya kelihatan dalam satu baris jadual NAT.

Mulakan dengan apa yang klien boleh dan tidak boleh capai

Dari klien yang bersambung, muat halaman yang berada di internet awam dan catat sama ada ia gagal serta-merta atau tersekat di tengah jalan. Kemudian buka sumber pada alamat peribadi pelayan VPN itu sendiri dan bandingkan kedua-dua hasil.

Alamat terowong yang menjawab ping sementara laman awam kehabisan masa ialah tanda masalah penghantaran atau terjemahan, bukan handshake yang rosak. Panel status klien sendiri tidak dapat membezakannya, kerana ia hanya tahu saluran kawalan sudah naik. Semak antara muka terowong di pelayan dengan ip -br addr show tun0 dan pastikan alamat yang diberikan kepada klien berada dalam kumpulan yang anda konfigurasikan. Jika kumpulan dan alamat klien tidak sepadan, betulkan itu dahulu, kerana setiap peraturan di bawah sepadan dengan kumpulan itu.

Seterusnya, tanya pelayan antara muka mana yang akan digunakannya untuk mencapai alamat awam. ip route get 203.0.113.9 mencetak peranti dan sumber yang dipilih pada baris pertamanya. Catat nama peranti itu, kerana itulah nilai yang mesti ada dalam peraturan NAT.

Baca peraturan yang menentukan sama ada paket keluar

MASQUERADE menulis semula paket hanya apabila paket keluar melalui antara muka yang dinamakan dalam peraturan. Peraturan yang terhad kepada peranti berwayar tidak melakukan apa-apa untuk trafik yang keluar melalui Wi-Fi, dan paket itu mengekalkan alamat sumber peribadinya hingga ke penghala huluan. Penghala itu tiada laluan balik ke kumpulan terowong anda, jadi ia membuang balasan, dan klien melihat sambungan yang terbuka lalu mati. Gejala bertambah dengan berapa banyak halaman yang tiba sebelum balasan pertama diperlukan.

Senaraikan jadual hidup dan baca lajur antara muka keluar daripada hanya mencari perkataan MASQUERADE. Output bentuk tambah lebih mudah dibandingkan daripada senarai berformat:

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

Pada Raspberry Pi yang dahulunya menggunakan Ethernet dan kini menggunakan Wi-Fi, nama lama hampir selalu menjadi seluruh cerita. Pemasang merekodkan peranti yang ada semasa persediaan, dan set peraturan yang disimpan memainkannya semula pada setiap but. Bandingkan peranti daripada carian laluan dengan peranti dalam peraturan sebelum menukar apa-apa lagi. Jika kedua-duanya sepadan, antara muka bukan masalah anda dan anda patut beralih kepada pembilang di bahagian terakhir. Jika berbeza, pembetulannya ialah suntingan satu perkataan dalam fail ketekalan.

Betulkan set peraturan yang disimpan, bukan hanya yang sedang berjalan

Menyunting jadual hidup sahaja bertahan sehingga but semula seterusnya, yang cukup lama untuk meyakinkan anda bahawa masalah sudah selesai. Peraturan yang kembali semasa but tinggal dalam fail yang dimuat semula oleh pakej ketekalan firewall. Pada imej Pi berasaskan Debian fail itu biasanya /etc/iptables/rules.v4.

Ambil salinan sebelum menyentuhnya, kemudian gantikan antara muka keluar pada baris MASQUERADE dengan peranti yang anda catat, contohnya -o wlan0 bukan -o eth0. Biarkan julat sumber seperti sedia ada, melainkan kumpulan klien anda telah berubah. Muat semula dan pastikan peraturan kini menyebut peranti yang betul:

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 tetapan bersebelahan mudah dilupakan. sysctl net.ipv4.ip_forward mesti melaporkan 1, dan penghala huluan tidak boleh menapis alamat sumber peribadi sendiri.

Buktikan peraturan itu tercetus, kemudian asingkan apa yang masih perlahan

Pembilang ialah satu-satunya bukti jujur bahawa sesuatu peraturan sepadan. Jalankan senarai terperinci, mulakan muat turun pada klien dan jalankannya semula. Lajur paket dan bait di sebelah peraturan anda sepatutnya meningkat, dan peraturan yang kekal pada sifar masih tidak sepadan. Jika pembilang bergerak tetapi halaman masih gagal, bandingkan julat sumber dengan kumpulan sebenar menggunakan grep -n "^server " /etc/openvpn/server.conf. Jika ia bergerak dan halaman dimuatkan tetapi daya pemprosesan lemah, terjemahan sudah selesai dan masalah yang tinggal ada di tempat lain.

Bandingkan dua pemindahan dari klien yang sama, satu ke hos pada rangkaian tempatan dan satu melalui terowong ke hos yang sama. Perlahan dalam kedua-dua kes menunjuk kepada pautan huluan Pi atau sambungan Wi-Fi, bukan VPN. Perlahan hanya melalui terowong menunjuk kepada MTU dan penghantaran semula, yang boleh anda periksa dengan ip -s link show tun0 sebelum menukar mana-mana tetapan kripto.

Untuk membatalkan eksperimen, pulihkan salinan dan muat semula, kemudian pastikan peraturan asal dan pembilangnya kembali. Tulis peranti keluar dan arahan muat semula dalam nota pelayan, kerana perubahan pautan huluan seterusnya akan menemui ketidakpadanan yang sama semula. Peraturan yang menyebut peranti salah kekal tidak kelihatan sehingga trafik memerlukannya.