Klien VPN terhubung tetapi tidak ada internet: tiga bagian yang hilang

Klien mendapat alamat, server menjawab ping, dan setiap halaman tetap kehabisan waktu. Sebagian besar orang mulai mengedit profil klien pada titik ini, yang biasanya usaha sia-sia: begitu tunnel menyala, server harus berperilaku seperti router. Tiga syarat harus terpenuhi sekaligus sebelum sebuah paket keluar dan balasan kembali, dan gejalanya sama saja mana pun yang hilang.

Mengapa tunnel yang berfungsi tetap tidak punya jalan keluar

Kernel harus meneruskan paket antar antarmuka, yang secara bawaan mati pada sebagian besar distribusi Linux. Lalu lintas harus diterjemahkan ke alamat yang bisa dijawab dunia luar, kecuali setiap router hulu sudah tahu rute kembali ke subnet tunnel. Jalur penerusan firewall harus mengizinkan lalu lintas di kedua arah, termasuk balasannya.

Masing-masing bisa diperbaiki secara terpisah, dan di situlah jebakannya. Menyalakan penerusan tanpa aturan penerjemahan membuat paket keluar dengan sumber privat dan tanpa jalur kembali. Menambahkan penerjemahan tanpa aturan penerusan membuat kernel menjatuhkan paket satu langkah kemudian.

Jadi ujilah ketiga lapisan alih-alih klien, dan ubah satu per satu agar hasilnya bermakna.

Penerusan adalah sakelar kernel yang harus dibuat permanen

Periksa nilai saat ini sebelum mengubahnya, lalu setel dan pastikan perubahannya berlaku.

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

Perintah pertama melaporkan nilai saat ini, yang kedua menyetelnya saat berjalan, dan yang ketiga membuktikan penulisan berhasil. Nilai saat berjalan hilang pada boot berikutnya, karena itu sesi yang berfungsi bisa rusak setelah pemeliharaan tanpa perubahan konfigurasi apa pun.

Buat permanen dalam berkas di bawah /etc/sysctl.d/, lalu terapkan berkas itu alih-alih melakukan boot ulang untuk mengetahuinya. Di FreeBSD padanannya net.inet.ip.forwarding, dengan gateway_enable=YES di rc.conf untuk kegigihan. Perangkat yang melaporkan penerusan nonaktif menjelaskan seluruh kelas laporan „paket datang dan tidak ada yang kembali”. Periksa pengaturan itu juga setelah setiap peningkatan, karena kernel yang dibangun ulang atau citra perangkat yang diganti dapat mengatur ulangnya tanpa memberi tahu siapa pun.

Pilih masquerade atau satu alamat penerjemahan tetap

Dengan alamat luar dinamis, masquerading adalah bentuk benar yang paling sederhana. Sebut subnet tunnel sebagai sumber dan antarmuka luar sebagai jalan keluar.

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

Dengan alamat publik statis, penerjemahan sumber ke alamat persis itu lebih dapat diprediksi 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 jebakan pemeliharaan: alamat yang dikodekan keras lalu berubah membuat tunnel tetap berfungsi sementara akses internet diam-diam berhenti. Entah gunakan masquerade atau perbarui aturannya setiap kali penyedia memindahkan Anda. Antarmuka juga penting, karena router yang berbagi tunnel hulunya sendiri harus menerjemahkan lewat tunnel itu, bukan lewat WAN fisik.

Tabel filter adalah gerbang ketiga

Penerusan dan penerjemahan bisa sama-sama benar sementara paket tetap mati di tabel filter. ufw sering menjadi pelakunya: kebijakan penerusannya dikirim sebagai DROP, dan sisa penyiapan bisa terlihat sepenuhnya benar sementara satu pengaturan itu membunuh lalu lintas. Menaikkannya adalah keputusan keamanan yang disengaja, bukan kotak centang.

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

Aturan pertama mengizinkan lalu lintas baru dari tunnel ke luar, dan yang kedua hanya balasan kembali. Sempitkan keduanya ke subnet tunnel dan tujuan yang dimaksud, karena penerimaan menyeluruh pada antarmuka tunnel mengubah VPN menjadi titik keluar terbuka bagi siapa pun yang bisa mengautentikasi.

Tunnel yang dijembatani membutuhkan jawaban berbeda. Alamatnya milik jembatan, bukan port fisik, jadi memperbudak antarmuka menghapus alamat yang dulu dimilikinya dan host tampak tak terjangkau sampai jembatan itu sendiri mendapatkannya, yang bisa disediakan dhclient br0. Kegagalan itu tampak seperti masalah VPN dan sebenarnya masalah lapisan dua. Periksa alamat jembatan itu sendiri sebelum menyentuh firewall, karena perubahan filter tidak bisa memperbaiki host yang tidak lagi punya alamat untuk mengirim.

Ke mana harus melihat saat halaman tidak pernah dimuat

Ping alamat tunnel server untuk membuktikan tunnel ada. Lalu jalankan traceroute dari klien ke alamat publik dan baca di mana ia berhenti: di server paket tiba tetapi tidak diteruskan atau diterjemahkan; di luar server masalahnya di hulu dan di luar kendali Anda.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Perintah pertama membuktikan tunnel membawa lalu lintas ke server itu sendiri, dan yang kedua menunjukkan seberapa jauh paket mencapai luar. Jejak yang berakhir di alamat tunnel menunjuk pada penerusan atau penerjemahan di server, sedangkan jejak yang berhenti satu hop kemudian menunjuk pada penyedia atau rute kembali router hulu.

Di server, amati antarmuka luar saat klien memuat halaman. Lalu lintas yang keluar dengan alamat sumber privat berarti penerjemahan hilang, dan tidak ada balasan sama sekali berarti jalur penerusan atau rute kembali hulu menjatuhkannya.

Jika klien jarak jauh juga harus mencapai host di LAN server, ingat bahwa LAN membutuhkan rute kembali ke subnet tunnel. Itu perutean, bukan penerjemahan, dan itulah langkah yang paling sering terlupakan setelah jalur internet akhirnya berfungsi.