Bersambung ke OpenVPN tetapi tiada apa yang dimuatkan: penelusuran dari klien

Tetingkap klien menyatakan Connected, alamat tunnel ada, dan pelayar masih berputar. Gabungan itu normal, kerana jabat tangan yang berjaya hanya membuktikan tunnel telah dibina; ia tidak menyatakan sama ada pelayan akan meneruskan paket anda, menulis semula sumbernya atau menjawab pertanyaan DNS anda. Kesilapan yang paling kerap dilakukan ialah membuka konfigurasi pelayan terlebih dahulu. Sebaliknya bergerak dari klien ke luar, kerana setiap langkah di bawah memberitahu sama ada langkah seterusnya wajar diperiksa.

Mula pada klien dan bergerak ke luar

Jalankan tiga ujian mengikut urutan ini dan catat di mana yang pertama gagal. Ping alamat tunnel pelayan, yang membuktikan tunnel itu sendiri membawa trafik. Ping alamat awam mengikut nombor, yang membuktikan penerusan dan terjemahan tanpa melibatkan penyelesaian nama. Kemudian cuba selesaikan nama hos, iaitu satu-satunya ujian yang menggunakan DNS. Setiap hasil membuang satu lapisan penuh daripada syak wasangka.

Jangan melompat ke ujian ketiga kerana pelayar terasa lebih pantas. Pemuatan halaman yang gagal meliputi ketiga-tiga lapisan sekali gus, dan dari situlah orang mula dan kemudian membina semula tunnel yang berfungsi. Halaman yang gagal tidak memberitahu lapisan mana antara tiga yang rosak.

Dua tangkapan menunjukkan di mana paket berhenti

Semasa ping ke alamat awam berjalan dari klien, ambil satu tangkapan pada antara muka tunnel dan satu pada pautan atas yang sepatutnya sampai ke internet. Jalankan kedua-duanya serentak supaya cap masa sepadan.

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

Jika permintaan muncul pada tunnel dan tidak pernah pada pautan atas, pelayan telah membuangnya antara tunnel dan kabel, dan puncanya ialah penerusan atau dasar tembok api penerusan, bukan NAT. Jika ia muncul pada kedua-duanya, pelayan telah melakukan bahagiannya dan jawapannya hilang lebih jauh ke luar, yang menunjuk kepada terjemahan, penapis di hulu atau sekatan daripada penyedia.

Ambil nama pautan atas daripada jadual penghalaan, bukan daripada tutorial. Imej awan dan penyesuai yang dinamakan semula jarang sepadan dengan antara muka contoh dalam panduan, dan tangkapan pada peranti yang salah kelihatan sama seperti pelayan yang tidak meneruskan:

ip -4 route get 9.9.9.9

Medan dev dalam keluaran itu ialah nama yang akan diperlukan oleh peraturan NAT kemudian, jadi simpanlah.

Penerusan ialah suis kernel dan dasar tembok api

Kernel mesti bersetuju untuk meneruskan terlebih dahulu. Baca nilai semasa, kemudian jadikan tetapan itu kekal dan bukan sekadar menulisnya ke dalam 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 separuh. Pada hos yang menggunakan UFW, dasar penerusan ditetapkan dalam /etc/default/ufw dan mesti ACCEPT sebelum muat semula berkuat kuasa. Penolakan lalai pada laluan penerusan membiarkan jabat tangan kekal sihat sepenuhnya sambil membuang diam-diam setiap paket yang cuba keluar melalui tunnel, dan itulah tepat gejala yang anda mulakan.

Hos yang mengurus nftables secara langsung menghadapi soalan yang sama dalam sintaksis lain. Perhatikan pembilang pada rantaian penerusan semasa ujian klien berjalan, kerana rantaian yang dirujuk dan rantaian yang membuang kelihatan sama dalam fail konfigurasi.

Namakan antara muka keluar sebenar dalam peraturan NAT

Terjemahan sumber sepatutnya berada pada antara muka yang benar-benar meninggalkan hos, dengan kumpulan alamat yang diagihkan oleh pelayan. Kedua-dua bahagian peraturan itu mesti menggambarkan realiti, dan tiada satu pun pilihan.

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

Kegagalan klasik ialah peraturan yang disalin daripada panduan yang menyebut -o eth0 pada mesin yang penyesuainya bernama lain. Peraturan itu dipasang tanpa amaran, tidak sepadan dengan apa-apa, dan klien masih tiada internet. Kumpulan alamat ialah separuh lagi kesilapan yang sama: jika pelayan mengagihkan 10.44.0.0/24 dan peraturan meliputi 10.8.0.0/24, tiada apa akan pernah sepadan.

Perhatikan pembilang dan bukan mempercayai teks peraturan. Senarai melaporkan paket bagi setiap peraturan, dan peraturan yang tidak pernah sepadan kekal pada sifar walau sesahih mana pun ia kelihatan. Beri ia satu minit trafik klien sebenar sebelum membaca apa-apa daripada nombor itu:

iptables -t nat -L POSTROUTING -v -n

Kiraan paket sifar selepas ujian klien sebenar bermaksud padanan itu salah, bukan tunnel itu rosak. Sebaik sahaja ia sepadan, simpan set peraturan supaya ia bertahan selepas but semula; pembetulan yang hanya hidup dalam sejarah shell anda hilang pada permulaan semula pertama.

Jika pelayan juga merupakan instans NAT awan, platform juga ada suara. Instans yang menterjemah alamat biasanya memerlukan pemeriksaan sumber dan destinasi dimatikan di tempat penyedia menawarkan tetapan itu, dan port VPN itu sendiri mesti boleh dicapai dari luar.

DNS ialah kegagalan kedua di belakang yang pertama

Ping mengikut alamat yang berfungsi sementara nama gagal ialah masalah penyelesai, dan ia mempunyai puncanya sendiri. Klien yang mengekalkan penyelesai tempatannya menghantar pertanyaan itu ke dalam tunnel penuh dan menunggu jawapan yang tidak pernah datang, kerana penyelesai tempatan kini berada di sebelah laluan yang salah.

Tolak penyelesai dari pelayan supaya klien tahu ke mana hendak bertanya. Dua entri memberi klien sandaran jika yang pertama tidak dapat dicapai, dan kedua-duanya sepatutnya penyelesai yang benar-benar dibenarkan oleh tunnel.

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

Klien Windows kemudian mungkin kembali ke penyelesai tempatan juga, dan itulah yang block-outside-dns wujud untuk menghalang, dengan kos kehilangan nama yang hanya rangkaian tempatan dapat selesaikan. Klien Linux dengan systemd-resolved sering mengabaikan penyelesai yang ditolak melainkan skrip memasangnya, jadi periksa resolvectl status untuk peranti tunnel sebelum membuat kesimpulan bahawa penolakan itu diabaikan.

Selesaikan penelusuran seperti yang dialami oleh pengguna. Muat halaman sebenar dari klien, sahkan alamat asal keluarnya, but semula pelayan, sambung semula dan ulangi tiga ujian itu. Hanya pusingan kedua itulah yang membuktikan peraturan yang disimpan, dasar tembok api dan penyelesai yang ditolak semuanya bertahan bersama.