Віртуальны мост TAP у pfSense: тры месцы, дзе можа загінуць кадр
Мост, яго ўдзельнікі і віртуальны камутатар вырашаюць кожны асобна. Знайдзіце, які ўладальнік фільтраваў, перш чым адключаць кіраванне, якога ніколі не было на шляху.
Вы адключаеце правіла на інтэрфейсе LAN, кадр усё роўна знікае, і выснова такая, што pfSense ігнаруе свой уласны фаервол. Звычайна адбываецца тое, што рашэнне прыняў іншы ўладальнік: сам мост, інтэрфейс-удзельнік або віртуальны камутатар па-за гасцем. Кожны мае сваё кіраванне і свой журнал.
Тры мяжы ніжэй варта раздзяляць перад зменай налады, бо адключэнне адной не кампенсуе іншую.
Адзін кадр, тры ўладальнікі палітыкі
Кадр ад кліента TAP уваходзіць праз тунельны прыбор, перасякае мост pfSense, выходзіць праз удзельнік LAN і затым праходзіць віртуальны камутатар, перш чым дасягнуць чаго-небудзь. Унутры гасця фільтраванне можа адбывацца на мосце або на інтэрфейсах-удзельніках, і тое, які з іх актыўны, — гэта выбар канфігурацыі, а не ўласцівасць. Па-за гасцем гіпервізар вырашае, ці можа гэты віртуальны адаптар перадаваць кадры з крынічным MAC, які яму не належыць. Скід у любым з гэтых пунктаў выглядае аднолькава з боку кліента.
Запішыце меркаваны шлях перад расследаваннем: тунельны ўдзельнік, мост, удзельнік LAN, віртуальны камутатар, пункт прызначэння. Затым спытайце, які ўладальнік на гэтым шляху ўбачыў бы кадр.
Якое кіраванне pfSense фільтруе
pfSense дакументуе для гэтага два sysctl: адзін для фільтравання на ўдзельніках моста і адзін для фільтравання на самім мосце, і хаця б адзін з іх павінен заставацца ўключаным. Фільтраванне на ўзроўні моста датычыцца трафіку, які прыходзіць праз удзельнікі моста, таму яно па накіраванню ўваходнае, а не сіметрычнае. Чытайце правілы на тым інтэрфейсе, які фактычна фільтруе, бо правіла, зададзенае на ўдзельніку без ролі фільтравання, не робіць нічога. Дакументацыя па фільтраванні моста тлумачыць прыналежнасць.
Інтэрфейс-удзельнік без IP-адраса не мае ўласнага макраса адраса або падсеткі, таму правіла, напісанае супраць гэтага макраса, можа апісваць нешта іншае, чым патрэбная вам LAN. Выкарыстоўвайце наўмысна прызначаныя сеткавыя аб'екты замест макрасаў для зручнасці.
Фрагмент — не кадр
Кадры Ethernet пераносяць IP-пакеты, а IP-пакет можа быць фрагментам большай дэтаграмы, таму гэтыя два словы не ўзаемазаменныя. Ёсць таксама ўнутраны пакет унутры тунеля і вонкавы транспартны пакет звонку, і адмова можа належаць любому з іх. Малы ping правярае адзін шлях праз гэты стек і нічога не даказвае пра вялікую перадачу. Параўнайце няўдалы абмен на дзвюх суседніх межах і прачытайце прычыну скіду, перш чым вінаваціць правіла.
Калі фрагменты знікаюць, адказ — абмежаваная карэкцыя або даследаванне памеру пакета, а не рашэнне цалкам адключыць фільтраванне.
Гіпервізар мае ўласнае рашэнне аб допуску
Госць, які мосціць трафік для іншых машын, перадае кадры, крынічныя MAC-адрасы якіх не належаць яго адаптару, і многія віртуальныя камутатары лічаць гэта падменай, калі група партоў гэтага не дазваляе. Дазвол на гэтую перадачу і дазвол адаптару прымаць кожны кадр — гэта асобныя кіраванні, і ўключэнне абодвух усюды — значна большая змена, чым патрабуе праблема. Вызначце, якія кадры мост павінен прымаць і павінен перадаваць, затым дайце толькі гэтыя паводзіны на той мяжы, якой яны належаць. Захавайце доступ да кансолі перад зменай моста, які кіруецца аддалена.
Аднаўленне злучэння — гэта палова тэсту; другая палова — пацвердзіць, што паток, які павінен заставацца заблакаваным, усё яшчэ заблакаваны.
Запішыце, які ўладальнік фільтраваў, якое кіраванне зменена і якія два патокі вы праверылі. Гэты запіс не дазваляе наступнаму інцыдэнту пачацца з той жа здагадкі, што pfSense ігнаруе сам сябе.