Jembatan TAP pfSense virtual: tiga tempat sebuah frame bisa mati

Anda menonaktifkan aturan di antarmuka LAN, frame tetap hilang, dan kesimpulannya adalah pfSense mengabaikan firewall-nya sendiri. Yang biasanya terjadi adalah pemilik lain yang mengambil keputusan: jembatan itu sendiri, antarmuka anggota, atau sakelar virtual di luar tamu. Masing-masing punya kontrol dan lognya sendiri.

Tiga batas di bawah ini layak dipisahkan sebelum Anda mengubah pengaturan, karena menonaktifkan satu tidak bisa menggantikan yang lain.

Satu frame, tiga pemilik kebijakan

Frame dari klien TAP masuk melalui perangkat terowongan, melewati jembatan pfSense, keluar melalui anggota LAN, lalu melewati sakelar virtual sebelum mencapai apa pun. Di dalam tamu, pemfilteran dapat terjadi di jembatan atau di antarmuka anggota, dan mana yang aktif adalah pilihan konfigurasi, bukan sifat tetap. Di luar tamu, hypervisor memutuskan apakah adaptor virtual itu boleh mengirim frame dengan MAC sumber yang bukan miliknya. Penurunan di salah satu titik itu terlihat sama dari sisi klien.

Tuliskan jalur yang dimaksud sebelum menyelidiki: anggota terowongan, jembatan, anggota LAN, sakelar virtual, tujuan. Lalu tanyakan pemilik mana di jalur itu yang akan melihat frame tersebut.

Kontrol pfSense mana yang memfilter

pfSense mendokumentasikan dua sysctl untuk ini, satu untuk pemfilteran pada anggota jembatan dan satu untuk pemfilteran pada jembatan itu sendiri, dan setidaknya salah satunya harus tetap aktif. Pemfilteran tingkat jembatan berlaku untuk lalu lintas yang datang melalui anggota jembatan, jadi ia bersifat masuk secara orientasi, bukan simetris. Baca aturan pada antarmuka yang benar-benar memfilter, karena aturan pada anggota tanpa peran pemfilteran tidak melakukan apa pun. Dokumentasi pemfilteran jembatan menjelaskan kepemilikannya.

Antarmuka anggota tanpa alamat IP tidak memiliki makro alamat atau subnet sendiri, jadi aturan yang ditulis terhadap makro itu dapat menjelaskan sesuatu selain LAN yang Anda maksud. Gunakan objek jaringan yang diberikan dengan sengaja alih-alih makro kenyamanan.

Fragmen bukan frame

Frame Ethernet membawa paket IP, dan paket IP dapat berupa fragmen dari datagram yang lebih besar, jadi kedua kata itu tidak dapat dipertukarkan. Ada juga paket dalam di dalam terowongan dan paket transport luar di luarnya, dan kegagalan bisa menjadi milik keduanya. Ping kecil menguji satu jalur melalui tumpukan itu dan tidak membuktikan apa pun tentang transfer besar. Bandingkan pertukaran yang gagal pada dua batas yang berdekatan dan baca alasan penurunan sebelum menyalahkan aturan.

Jika fragmen menghilang, jawabannya adalah koreksi terbatas atau penyelidikan ukuran paket, bukan keputusan menonaktifkan pemfilteran sepenuhnya.

Hypervisor punya keputusan penerimaannya sendiri

Tamu yang menjembatani lalu lintas untuk mesin lain mengirim frame yang alamat MAC sumbernya bukan milik adaptornya sendiri, dan banyak sakelar virtual menganggapnya sebagai pemalsuan kecuali grup port mengizinkannya. Mengizinkan pengiriman itu dan mengizinkan adaptor menerima setiap frame adalah kontrol terpisah, dan mengaktifkan keduanya di mana-mana adalah perubahan yang jauh lebih besar daripada yang dibutuhkan masalah. Tentukan frame mana yang harus diterima dan harus dikirim jembatan, lalu berikan hanya perilaku itu pada batas yang memilikinya. Pertahankan akses konsol sebelum mengubah jembatan yang dikelola dari jarak jauh.

Memulihkan konektivitas adalah separuh ujian; separuh lainnya adalah memastikan aliran yang seharusnya tetap diblokir masih diblokir.

Catat pemilik mana yang memfilter, kontrol mana yang diubah, dan dua aliran mana yang Anda verifikasi. Catatan itu mencegah insiden berikutnya dimulai dengan dugaan yang sama bahwa pfSense mengabaikan dirinya sendiri.