Membuka port VPN tidak membuat klien mencapai LAN

Tunnel naik, klien terautentikasi, tetapi LAN di belakang gateway tetap tidak terlihat. Aturan yang seharusnya memperbaikinya mengizinkan port VPN dan bekerja persis seperti tertulis, karena aturan itu mengatur paket yang dialamatkan ke gateway itu sendiri. Lalu lintas klien ke host di belakang gateway memiliki tujuan lain dan rantai lain. Login yang berhasil tidak mengubah rantai mana yang diperiksa kernel.

Dua rantai, dua tujuan berbeda

Nasib paket ditentukan oleh ke mana ia pergi, bukan bagaimana ia datang. Lalu lintas ke alamat di gateway dikirim secara lokal dan dinilai dengan aturan masukan. Lalu lintas yang diteruskan gateway dinilai dengan aturan penerusan. Antarmuka tunnel yang sama dapat menghasilkan kedua jenis paket, karena itu satu aturan tidak dapat mencakup kedua tugas.

Seluruh mitos dalam satu kalimat: mengizinkan pendengar tidak mengatakan apa pun tentang mengizinkan jaringan di belakangnya. Keduanya keputusan terpisah dengan bukti terpisah, dan nama antarmuka pada keduanya tidak menyatukannya.

Apa yang sebenarnya diizinkan aturan pendengar

Paket pendengar berakhir di proses VPN, dan itulah yang memungkinkan tunnel dibangun. Halaman administrasi gateway dan balasan diagnostik lokal juga memakai jalur masukan host itu sendiri, karena itu uji ke gateway berhasil sementara semua yang di belakangnya gagal. Kedua hasil benar dan tidak satu pun tentang LAN.

Ketika proses mendekapsulasi lalu lintas klien untuk tujuan lain, paket masuk ke jalur penerusan dan membutuhkan izin di sana. Autentikasi yang berhasil memutuskan siapa klien; itu tidak memutuskan ke mana klien boleh pergi. Kedua pertanyaan punya pemilik, log, dan pesan galat yang berbeda.

Uji dari klien, jangan pernah dari gateway

Uji yang dibuat di gateway mengikuti jalur keluaran host itu sendiri dan bisa lolos sementara jalur penerusan tertutup. Mulai uji dari klien dan amati kedua ujung aliran.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Jika permintaan muncul di tun0 dan tidak ada yang mencapai tujuan, paket dibuang setelah tiba, yang menunjuk ke aturan penerusan atau penyaringan tujuan itu sendiri. Jika tidak ada apa pun muncul di tun0, klien bahkan tidak mengirimkannya ke tunnel, dan masalahnya ada pada perutean di klien, bukan kebijakan di gateway. Bandingkan dengan permintaan yang keluar dengan benar dan tidak mengembalikan apa pun, yaitu kasus jalur balik.

Penerusan membutuhkan tiga hal, bukan satu

Penerusan kernel harus diaktifkan, aturan filter harus menerima aliran, dan tujuan harus dapat dijangkau dengan jalur untuk balasan kembali. Jika salah satu dari tiga itu hilang, kesunyiannya sama dari sudut pandang klien.

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

Baca ketiga keluaran bersama. Nol pada yang pertama membuat dua lainnya tidak relevan, dan kebijakan buang bawaan pada yang kedua membuang paket klien sementara lalu lintas gateway sendiri tetap berjalan. Keluaran ketiga menunjukkan mengapa aturan pendengar tidak pernah menjadi masalah.

Pisahkan kedua kumpulan aturan dalam dokumentasi

Tulis aturan pendengar dan aturan layanan yang diteruskan pada baris terpisah, dengan pemilik dan alasan terpisah. Ketika port VPN berubah atau layanan baru diterbitkan, pemisahan itu mencegah satu perubahan diam-diam memperlebar yang lain.

Daripada memperlakukan setiap rekan terautentikasi sebagai anggota LAN tepercaya, gunakan aturan sempit untuk rentang klien dan layanan yang membutuhkannya. Catatan penerusan StrongSwan menjelaskan sisi rute balik dan penerjemahan dari batas yang sama, yang lagi-lagi keputusan ketiga.

Terakhir, jaga lapisan tetap lurus ketika pengguna ditolak. Jika permintaan mencapai host dan aplikasi menolak akun, perbaiki izin aplikasi pada lapisan itu; memperlebar penerusan tidak dapat menyediakan kredensial berbagi berkas dan akan memperlebar akses bagi semua orang lain yang berhasil terhubung.