Firewall cloud versus firewall host untuk server VPN

Izinkan port VPN di kebijakan cloud dan handshake masih bisa mati di instans: tamu menjalankan filternya sendiri dan pengikatan listener-nya sendiri, dan keduanya dapat membuang apa yang telah disetujui cloud. Kebalikannya juga terjadi, ketika aturan host mengizinkan port dan kebijakan di atasnya membuangnya lebih dulu. Dua pemilik, dua set aturan, satu jalur paket. Telusuri berurutan alih-alih menebak pada lapisan yang paling mencurigakan.

Mulai dari tepi dan berjalan ke dalam

Urutannya tetap: endpoint publik, antarmuka sumber daya, kebijakan cloud yang terpasang, alamat tamu, listener proses, aturan input lokal. Setiap tahap meneruskan paket atau mengakhiri penyelidikan, karena itu memulai dari tamu paling banyak membuang waktu.

Lalu lintas klien yang diteruskan adalah tahap terpisah, diperiksa setelah tunnel didekapsulasi. Lapisan cloud hanya melihat tunnel luar, jadi ia dapat menyetujui koneksi dan tetap tidak ada hubungannya dengan permintaan layanan internal. Tunnel yang tersambung tetapi tidak mencapai host internal biasanya menunjuk ke penerusan, bukan ke port tertutup.

Baca kebijakan cloud sebelum menyentuh tamu

Pastikan aturan masuk untuk port VPN, protokolnya, dan cakupan sumber yang cocok dengan klien uji Anda. Periksa juga daftar kontrol akses subnet: filter kedua dengan aturan dan nilai bawaannya sendiri. Keduanya harus mengizinkan aliran sebelum paket mencapai instans. Izin di satu dan tolakan di lainnya adalah bentuk lazim dari bug ini.

Sempitkan cakupan sampai bermakna. Membuka port VPN ke seluruh internet mudah dibuktikan dan sulit dipertahankan, sedangkan aturan yang dipatok ke satu alamat rusak ketika klien uji Anda berpindah jaringan. Catat pengenal aturan dan pemilik kebijakan, agar perubahan berikutnya dapat dilacak ke seseorang.

Pastikan listener, lalu rantai input

Di instans, periksa bahwa proses VPN terikat ke alamat dan port yang Anda harapkan, misalnya dengan ss -lntp 'sport = :1194'. Daemon yang hanya terikat ke 127.0.0.1 menerima klien lokal dan tidak menerima apa pun lewat tunnel, yang dari luar tampak persis seperti port tersaring.

Lalu baca aturan lokal dalam sintaks yang akan Anda pakai untuk mengubahnya, seperti iptables -S INPUT atau nft list chain inet filter input. Aturan yang ditulis ke berkas tetapi tidak pernah dimuat, atau drop bawaan tanpa izin yang cocok, membuang paket secara diam-diam. Untuk gateway penerus, periksa juga pengaturan penerusan dan jalur balik. Itu menentukan apa yang terjadi pada paket yang dirutekan melalui instans, bukan yang dialamatkan kepadanya.

Stateful di satu lapisan, stateless di lapisan berikutnya

Grup keamanan mengingat aliran yang mereka izinkan dan mengizinkan balasannya masuk kembali. Daftar kontrol akses subnet dan banyak firewall host tidak menyimpan keadaan semacam itu, jadi aturan yang hanya mencakup arah keluar meloloskan permintaan dan membuang balasannya. Jangan pernah membawa asumsi tentang lalu lintas balik antar lapisan tanpa membaca aturan lapisan kedua (second layer's rule).

Penghitung menyelesaikannya lebih cepat daripada membaca setiap aturan di akun. Penghitung yang naik berarti paket tiba dan dibuang di situ, sedangkan yang beku di nol berarti paket tidak pernah sampai sejauh itu; iptables -vnL INPUT dan nft list ruleset menampilkan angka itu ketika aturan dimuat dengan penghitung.

Uji dengan sesi baru, bukan sesi hidup

Biarkan jaringan sumber dan profil uji tetap seperti adanya saat membandingkan tampilan, dan buka koneksi baru setelah setiap perubahan. Mencapai konsol web di 443 tidak mengatakan apa pun tentang apakah daemon VPN terikat ke 1194, jadi uji port yang Anda butuhkan. Sesi yang sudah ada adalah saksi terburuk di sini. Sesi itu tetap bekerja sementara setiap login baru ditolak.

Sebelum menyunting kebijakan jarak jauh, pastikan ada jalan kembali yang tidak bergantung pada jalur yang Anda ubah. Lalu buka sesi administrasi kedua di samping uji VPN: sesi yang dibuka lebih awal dapat bertahan lebih lama daripada aturan yang memblokir sesi baru. Catat pemilik kedua kebijakan agar tidak ada pembangunan ulang yang memulihkan separuh jalur; jika kedua lapisan setuju dan tunnel tetap gagal, tangkap lalu lintas di antarmuka tamu dan periksa alamat serta port yang benar-benar dipakai klien.