Klien VPN menyambung tetapi tiada internet: tiga bahagian yang hilang

Klien mendapat alamat, pelayan menjawab ping, dan setiap halaman masih tamat masa. Kebanyakan orang mula menyunting profil klien pada ketika ini, yang biasanya membazir usaha: apabila tunel naik, pelayan mesti berkelakuan seperti penghala. Tiga syarat mesti dipenuhi serentak sebelum paket keluar dan balasan kembali, dan gejalanya sama sahaja mana pun yang hilang.

Mengapa tunel yang berfungsi masih tiada jalan keluar

Kernel mesti menghantar paket antara antara muka, yang dimatikan secara lalai pada kebanyakan pengedaran Linux. Trafik mesti diterjemah ke alamat yang boleh dijawab oleh dunia luar, kecuali setiap penghala huluan sudah tahu laluan balik ke subnet tunel. Laluan penghantaran tembok api mesti membenarkan trafik dalam kedua-dua arah, termasuk balasan.

Setiap satunya boleh dibaiki secara berasingan, dan di situlah perangkapnya. Menghidupkan penghantaran tanpa peraturan terjemahan membiarkan paket keluar dengan sumber peribadi dan tanpa laluan balik. Menambah terjemahan tanpa peraturan penghantaran membiarkan kernel menggugurkan paket satu langkah kemudian.

Jadi uji tiga lapisan itu dan bukan klien, dan ubah satu demi satu supaya hasilnya bermakna.

Penghantaran ialah suis kernel yang mesti dikekalkan

Semak nilai semasa sebelum mengubahnya, kemudian tetapkannya dan sahkan perubahan itu berkuat kuasa.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Perintah pertama melaporkan nilai semasa, yang kedua menetapkannya semasa berjalan, dan yang ketiga membuktikan tulisan itu berjaya. Nilai semasa berjalan hilang pada but berikutnya, sebab itu sesi yang berfungsi boleh rosak selepas penyelenggaraan tanpa sebarang perubahan konfigurasi.

Jadikan ia kekal dalam fail di bawah /etc/sysctl.d/, kemudian gunakan fail itu dan bukannya but semula untuk mengetahuinya. Pada FreeBSD persamaannya ialah net.inet.ip.forwarding, dengan gateway_enable=YES dalam rc.conf untuk kekekalan. Peranti yang melaporkan penghantaran dimatikan menjelaskan seluruh kelas laporan „paket datang dan tiada apa yang kembali”. Semak tetapan itu juga selepas setiap peningkatan, kerana kernel yang dibina semula atau imej peranti yang diganti boleh menetapkannya semula tanpa memberitahu sesiapa.

Pilih masquerade atau satu alamat terjemahan tetap

Dengan alamat luar dinamik, masquerading ialah bentuk betul yang paling mudah. Namakan subnet tunel sebagai sumber dan antara muka luar sebagai jalan keluar.

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

Dengan alamat awam statik, terjemahan sumber ke alamat tepat itu lebih boleh dijangka dan lebih mudah diaudit.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Bentuk kedua membawa perangkap penyelenggaraan: alamat yang dikodkan keras yang berubah kemudiannya mengekalkan tunel berfungsi sementara akses internet berhenti secara senyap. Sama ada gunakan masquerade atau kemas kini peraturan setiap kali penyedia memindahkan anda. Antara muka juga penting, kerana penghala yang berkongsi tunel huluannya sendiri mesti menterjemah keluar melalui tunel itu dan bukan melalui WAN fizikal.

Jadual penapis ialah pintu ketiga

Penghantaran dan terjemahan boleh kedua-duanya betul sementara paket masih mati dalam jadual penapis. ufw ialah pesalah kerap: dasar penghantarannya dihantar sebagai DROP, dan seluruh persediaan boleh kelihatan betul sepenuhnya sementara satu tetapan itu membunuh trafik. Menaikkannya ialah keputusan keselamatan yang disengajakan, bukan kotak semak.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Peraturan pertama membenarkan trafik baharu dari tunel ke luar, dan yang kedua hanya balasan kembali. Sempitkan kedua-duanya kepada subnet tunel dan destinasi yang dimaksudkan, kerana penerimaan menyeluruh pada antara muka tunel menjadikan VPN titik keluar terbuka kepada sesiapa yang boleh mengesahkan identiti.

Tunel berjambatan memerlukan jawapan berbeza. Alamat itu milik jambatan, bukan port fizikal, jadi memperhambakan antara muka membuang alamat yang dahulunya dimilikinya dan hos kelihatan tidak dapat dicapai sehingga jambatan itu sendiri menerima satu, yang boleh disediakan oleh dhclient br0. Kegagalan itu kelihatan seperti masalah VPN dan sebenarnya masalah lapisan dua. Semak alamat jambatan itu sendiri sebelum menyentuh tembok api, kerana perubahan penapis tidak boleh membaiki hos yang tidak lagi mempunyai alamat untuk menghantar.

Di mana hendak melihat apabila halaman tidak pernah dimuatkan

Ping alamat tunel pelayan untuk membuktikan tunel wujud. Kemudian jalankan traceroute dari klien ke alamat awam dan baca di mana ia berhenti: di pelayan paket tiba tetapi tidak dihantar atau diterjemah; di luar pelayan masalahnya di hulu dan di luar kawalan anda.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Perintah pertama membuktikan tunel membawa trafik ke pelayan itu sendiri, dan yang kedua menunjukkan sejauh mana paket sampai ke luar. Jejak yang berakhir di alamat tunel menunjuk kepada penghantaran atau terjemahan di pelayan, manakala jejak yang berhenti satu hop kemudian menunjuk kepada penyedia atau laluan balik penghala huluan.

Di pelayan, perhatikan antara muka luar sementara klien memuatkan halaman. Trafik yang keluar dengan alamat sumber peribadi bermakna terjemahan hilang, dan tiada balasan sama sekali bermakna laluan penghantaran atau laluan balik huluan menggugurkannya.

Jika klien jauh juga perlu mencapai hos di LAN pelayan, ingat bahawa LAN memerlukan laluan balik ke subnet tunel. Itu penghalaan dan bukan terjemahan, dan itulah langkah yang paling kerap dilupakan selepas laluan internet akhirnya berfungsi.