VPN Router Berfungsi tetapi Klien LAN Tidak Punya Internet

Status menyatakan tunnel aktif, browser di router itu sendiri memuat halaman, dan setiap perangkat di belakangnya tetap kehabisan waktu. Kombinasi itu mempersempit masalah ke lapisan yang tidak pernah disebutkan sebagian besar panduan VPN: router bukan satu-satunya host yang paketnya perlu bertahan melewati tunnel. Lalu lintas yang dibuat secara lokal dan lalu lintas yang diteruskan menempuh jalur berbeda di dalam perangkat yang sama. Uji dari klien dan perbedaannya berhenti menjadi teoretis.

Baca Kegagalan dari Host LAN

Mulailah dari perangkat yang gagal, karena menjalankan diagnostik di router menjawab pertanyaan yang berbeda. Pastikan gateway default klien adalah router ini, catat alamat sumber dan subnet-nya, lalu lihat apa yang keluar dari antarmuka tunnel router.

Jika alamat klien diterjemahkan, sisi jauh melihat alamat tunnel, dan dari sana semuanya tampak sehat sementara klien tetap gagal. Jika tidak diterjemahkan, sisi jauh harus mengetahui rute kembali ke subnet klien, dan banyak gateway tidak memiliki rute seperti itu secara default. Bagaimanapun juga, keberhasilan router sendiri tidak relevan, karena paketnya dibuat secara lokal dan tidak pernah melewati jalur penerusan.

Lalu Lintas Lokal dan Lalu Lintas yang Diteruskan Berbeda

Linux dan sebagian besar firmware router memperlakukan paket yang berasal dari perangkat itu secara berbeda dari paket yang melewatinya. Rantai output melihat jenis pertama, rantai forward melihat jenis kedua, dan kebijakan yang disetel untuk lalu lintas router sendiri dapat membiarkan penerusan tidak tersentuh.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Periksa apakah penerusan diaktifkan sama sekali, lalu baca rantai forward, bukan rantai output. Aturan yang mengizinkan koneksi luar terenkripsi bukan aturan yang mengizinkan paket terdekripsi diteruskan, dan mencampuradukkan keduanya menghasilkan gejala yang persis sama. Tunnel yang aktif hanya membuktikan yang pertama.

Jalur Balik Juga Harus Ada

Penerjemahan sumber menentukan apakah jalur balik diperlukan. Dengan masquerading pada antarmuka tunnel, balasan kembali ke alamat tunnel dan router menerjemahkannya kembali. Tanpa itu, gateway jauh memerlukan rute eksplisit ke subnet klien, dan kebijakannya sendiri harus mengizinkan arah tersebut.

Catat desain mana dari keduanya yang dipakai penerapan sebelum mengubah apa pun, karena perbaikannya menunjuk ke arah yang berlawanan. Menambahkan penerjemahan menyembunyikan rute balik yang hilang dan merusak aplikasi yang membutuhkan alamat sumber asli. Menambahkan rute balik tanpa penerjemahan gagal diam-diam ketika firewall jauh membuang sumber yang tidak dikenalnya. Pilih satu, dokumentasikan, dan buat sisi lain menyesuaikan.

DNS klien termasuk dalam tinjauan yang sama. Resolver router dapat menjawab sementara klien yang diarahkan ke server lain tidak mendapatkan apa pun.

Verifikasi Satu Alur yang Diizinkan dan Satu Alur yang Ditolak

Setelah koreksi, uji koneksi baru dari klien, bukan sesi router yang sudah ada. Lalu pastikan bahwa segmen yang seharusnya tidak menggunakan tunnel tetap tidak menggunakannya.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Periksa alamat sumber yang teramati di ujung jauh, karena itu memberi tahu Anda desain mana yang sebenarnya berjalan. Verifikasi pencarian nama sekaligus alamat, karena perilaku resolver adalah jalur terpisah melalui perangkat yang sama.

Batasi aturan pada jaringan klien yang membutuhkan tunnel, dan jangan menonaktifkan filter penerusan agar satu pengujian lolos. Perubahan itu memperbaiki pengujian dan menghapus batas yang seharusnya disediakan tunnel. Tulis alamat sumber, keputusan penerjemahan, dan rute balik dalam satu catatan, beserta tanggalnya.