Membuka port VPN tidak membolehkan klien mencapai LAN

Terowong naik, klien disahkan, tetapi LAN di belakang gateway kekal tidak kelihatan. Peraturan yang sepatutnya membaikinya membenarkan port VPN dan berfungsi tepat seperti ditulis, kerana peraturan itu mengawal paket yang dialamatkan kepada gateway itu sendiri. Trafik klien ke hos di belakang gateway mempunyai destinasi lain dan rantaian lain. Log masuk yang berjaya tidak mengubah rantaian mana yang diperiksa kernel.

Dua rantaian, dua destinasi berbeza

Nasib paket ditentukan oleh ke mana ia pergi, bukan bagaimana ia tiba. Trafik ke alamat pada gateway dihantar secara tempatan dan dinilai dengan peraturan input. Trafik yang diteruskan oleh gateway dinilai dengan peraturan pengusulan. Antara muka terowong yang sama boleh menghasilkan kedua-dua jenis paket, jadi satu peraturan tidak boleh meliputi kedua-dua tugas.

Seluruh mitos dalam satu ayat: membenarkan pendengar tidak berkata apa-apa tentang membenarkan rangkaian di belakangnya. Kedua-duanya keputusan berasingan dengan bukti berasingan, dan nama antara muka pada kedua-duanya tidak menyatukannya.

Apa yang sebenarnya dibenarkan oleh peraturan pendengar

Paket pendengar berakhir dalam proses VPN, dan itulah yang membolehkan terowong dibina. Halaman pentadbiran gateway dan balasan diagnostik tempatan juga menggunakan laluan input hos itu sendiri, sebab itu ujian ke gateway berjaya manakala semua di belakangnya gagal. Kedua-dua keputusan betul dan tiada satu pun tentang LAN.

Apabila proses menyahkapsul trafik klien untuk destinasi lain, paket masuk ke laluan pengusulan dan memerlukan kebenaran di sana. Pengesahan yang berjaya menentukan siapa klien; ia tidak menentukan ke mana klien boleh pergi. Kedua-dua soalan mempunyai pemilik, log dan mesej ralat yang berbeza.

Uji dari klien, jangan sekali-kali dari gateway

Ujian yang dijana pada gateway mengikut laluan output hos itu sendiri dan boleh lulus walaupun laluan pengusulan tertutup. Mulakan ujian dari klien dan perhatikan kedua-dua hujung aliran.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Jika permintaan muncul pada tun0 dan tiada apa sampai ke destinasi, paket dibuang selepas tiba, yang menunjuk kepada peraturan pengusulan atau penapisan destinasi itu sendiri. Jika tiada apa muncul pada tun0, klien tidak menghantarnya ke terowong pun, dan masalahnya ialah penghalaan pada klien bukan dasar pada gateway. Bandingkan dengan permintaan yang keluar dengan betul dan tidak mengembalikan apa-apa, iaitu kes laluan balik.

Pengusulan memerlukan tiga perkara, bukan satu

Pengusulan kernel mesti diaktifkan, peraturan penapis mesti menerima aliran, dan destinasi mesti boleh dicapai dengan laluan untuk balasan kembali. Jika satu daripada tiga tiada, kesunyiannya sama dari sudut pandangan klien.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Baca ketiga-tiga output bersama. Sifar pada yang pertama menjadikan dua lagi tidak relevan, dan dasar buang lalai pada yang kedua membuang paket klien manakala trafik gateway sendiri terus berfungsi. Output ketiga menunjukkan mengapa peraturan pendengar tidak pernah menjadi masalah.

Asingkan kedua-dua set peraturan dalam dokumentasi

Tulis peraturan pendengar dan peraturan perkhidmatan yang diteruskan pada baris berasingan, dengan pemilik dan sebab berasingan. Apabila port VPN berubah atau perkhidmatan baharu diterbitkan, pemisahan itu menghalang satu perubahan daripada melebarkan yang lain secara senyap.

Daripada menganggap setiap rakan yang disahkan sebagai ahli LAN yang dipercayai, gunakan peraturan sempit untuk julat klien dan perkhidmatan yang memerlukannya. Nota pengusulan StrongSwan menerangkan sisi laluan balik dan terjemahan sempadan yang sama, yang sekali lagi keputusan ketiga.

Akhir sekali, kekalkan lapisan lurus apabila pengguna ditolak. Jika permintaan sampai ke hos dan aplikasi menolak akaun, baiki kebenaran aplikasi pada lapisan itu; melebarkan pengusulan tidak boleh menyediakan kelayakan perkongsian fail dan akan melebarkan akses untuk semua yang lain yang berjaya menyambung.