VPN Router Berfungsi tetapi Klien LAN Tiada Internet

Status menyatakan terowong aktif, pelayar pada router itu sendiri memuatkan halaman, dan setiap peranti di belakangnya masih tamat masa. Gabungan itu menyempitkan masalah kepada lapisan yang tidak pernah disebut oleh kebanyakan panduan VPN: router bukan satu-satunya hos yang paketnya perlu bertahan melalui terowong. Trafik yang dijana secara setempat dan trafik yang dihantar ke hadapan melalui laluan berbeza dalam kotak yang sama. Uji dari klien dan perbezaannya tidak lagi bersifat teori.

Baca kegagalan dari hos LAN

Mulakan pada peranti yang gagal, kerana diagnostik yang dijalankan pada router menjawab soalan yang berbeza. Sahkan bahawa get laluan lalai klien ialah router ini, catat alamat sumber dan subnetnya, kemudian lihat apa yang keluar dari antara muka terowong router.

Jika alamat klien diterjemahkan, sisi jauh melihat alamat terowong, dan dari situ semuanya kelihatan sihat sementara klien masih gagal. Jika tidak diterjemahkan, sisi jauh mesti mengetahui laluan balik ke subnet klien, dan banyak get laluan tidak mempunyai laluan sedemikian secara lalai. Sama ada cara, kejayaan router itu sendiri tidak relevan, kerana paketnya dijana secara setempat dan tidak pernah melalui laluan penghantaran ke hadapan.

Trafik setempat dan trafik yang dihantar ke hadapan berbeza

Linux dan kebanyakan firmware router mengendalikan paket yang berasal dari kotak itu secara berbeza daripada paket yang melaluinya. Rantaian output melihat jenis pertama, rantaian forward melihat jenis kedua, dan dasar yang ditala untuk trafik router itu sendiri boleh membiarkan penghantaran ke hadapan 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 sama ada penghantaran ke hadapan diaktifkan, kemudian baca rantai forward dan bukan rantaian output. Peraturan yang membenarkan sambungan luar yang disulitkan bukan peraturan yang membenarkan paket dinyahsulit dihantar ke hadapan, dan mengelirukan kedua-duanya menghasilkan gejala ini dengan tepat. Terowong yang aktif hanya membuktikan yang pertama.

Laluan balik juga mesti wujud

Terjemahan sumber menentukan sama ada laluan balik diperlukan. Dengan masquerading pada antara muka terowong, balasan kembali ke alamat terowong dan router menterjemahkannya semula. Tanpanya, get laluan jauh memerlukan laluan eksplisit ke subnet klien, dan dasarnya sendiri mesti membenarkan arah itu.

Catat reka bentuk mana antara dua yang digunakan oleh penggunaan sebelum mengubah apa-apa, kerana pembaikan menunjuk ke arah yang bertentangan. Menambah terjemahan menyembunyikan laluan balik yang hilang dan memecahkan aplikasi yang memerlukan alamat sumber asal. Menambah laluan balik tanpa terjemahan gagal secara senyap apabila tembok api jauh menggugurkan sumber yang tidak dikenali. Pilih satu, dokumentasikan, dan padankan sisi yang lain.

DNS klien tergolong dalam semakan yang sama. Penyelesai router boleh menjawab sementara klien yang menghala ke pelayan lain tidak mendapat apa-apa.

Sahkan satu aliran dibenarkan dan satu aliran ditolak

Selepas pembetulan, uji sambungan baharu dari klien dan bukan sesi router sedia ada. Kemudian sahkan bahawa segmen yang tidak sepatutnya menggunakan terowong masih 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 diperhatikan di hujung jauh, kerana itu memberitahu anda reka bentuk mana yang sebenarnya berjalan. Sahkan carian nama serta alamat, kerana tingkah laku penyelesai ialah laluan berasingan melalui kotak yang sama.

Kekalkan peraturan terhad kepada rangkaian klien yang memerlukan terowong, dan jangan matikan penapis penghantaran ke hadapan semata-mata untuk meluluskan satu ujian. Perubahan itu membaiki ujian dan menghapuskan sempadan yang sepatutnya disediakan oleh terowong. Tulis alamat sumber, keputusan terjemahan dan laluan balik dalam satu nota, berserta tarikh.