Wirtualny most TAP w pfSense: trzy miejsca, w których ramka może zginąć

Wyłączasz regułę na interfejsie LAN, ramka nadal znika, a wniosek jest taki, że pfSense ignoruje własną zaporę ogniową. Zwykle stało się tak, że decyzję podjął inny właściciel: sam most, interfejs członkowski lub przełącznik wirtualny poza gościem. Każdy ma własną kontrolę i własny dziennik.

Trzy poniższe granice warto rozdzielić, zanim zmienisz ustawienie, ponieważ wyłączenie jednej nie może zrekompensować drugiej.

Jedna ramka, trzech właścicieli polityki

Ramka od klienta TAP wchodzi przez urządzenie tunelowe, przechodzi przez most pfSense, wychodzi przez członka LAN, a następnie przechodzi przez przełącznik wirtualny, zanim cokolwiek osiągnie. Wewnątrz gościa filtrowanie może odbywać się na moście lub na interfejsach członkowskich, a to, który jest aktywny, jest wyborem konfiguracji, a nie stałą właściwością. Poza gościem hiperwizor decyduje, czy ten wirtualny adapter może wysyłać ramki ze źródłowym MAC, którego nie posiada. Odrzucenie w którymkolwiek z tych punktów wygląda z perspektywy klienta identycznie.

Zapisz zamierzoną ścieżkę przed zbadaniem: członek tunelu, most, członek LAN, przełącznik wirtualny, cel. Następnie zapytaj, który właściciel na tej ścieżce widziałby ramkę.

Która kontrola pfSense filtruje

pfSense dokumentuje do tego dwa sysctle, jeden do filtrowania na członkach mostu i jeden do filtrowania na samym moście, i przynajmniej jeden z nich musi pozostać włączony. Filtrowanie na poziomie mostu dotyczy ruchu przychodzącego przez członków mostu, więc jest wejściowe pod względem kierunku, a nie symetryczne. Czytaj reguły na interfejsie, który naprawdę filtruje, ponieważ reguła ustawiona na członku bez roli filtrowania nie robi zupełnie nic. Dokumentacja filtrowania mostu wyjaśnia własność.

Interfejs członkowski bez adresu IP nie ma własnego makra adresu ani podsieci, więc reguła napisana przeciw temu makrowi może opisywać coś innego niż zamierzona LAN. Używaj celowo przypisanych obiektów sieciowych zamiast makr wygody.

Fragment nie jest ramką

Ramki Ethernet przenoszą pakiety IP, a pakiet IP może być fragmentem większego datagramu, więc te dwa słowa nie są wymienne. Wewnątrz tunelu jest też pakiet wewnętrzny, a na zewnątrz zewnętrzny pakiet transportowy, i awaria może należeć do każdego z nich. Mały ping sprawdza jedną ścieżkę przez ten stos i niczego nie dowodzi o dużym transferze. Porównaj nieudaną wymianę na dwóch sąsiednich granicach i przeczytaj powód odrzucenia, zanim obwinisz regułę.

Jeśli fragmenty znikają, odpowiedzią jest ograniczona poprawka lub badanie rozmiaru pakietu, a nie decyzja o całkowitym wyłączeniu filtrowania.

Hiperwizor ma własną decyzję o dopuszczeniu

Gość, który mostkuje ruch dla innych maszyn, emituje ramki, których źródłowe adresy MAC nie należą do jego własnego adaptera, i wiele przełączników wirtualnych traktuje to jako podszywanie się, o ile grupa portów na to nie pozwala. Zezwolenie na tę transmisję i zezwolenie adapterowi na odbiór każdej ramki to osobne kontrole, a włączenie obu wszędzie jest znacznie większą zmianą, niż wymaga problem. Ustal, które ramki most musi odbierać i które musi wysyłać, a następnie przyznaj tylko to zachowanie na granicy, która nim zarządza. Zachowaj dostęp do konsoli przed zmianą mostu zarządzanego zdalnie.

Przywrócenie łączności to połowa testu; druga połowa to potwierdzenie, że przepływ, który powinien pozostać zablokowany, nadal jest zablokowany.

Zapisz, który właściciel filtrował, która kontrola się zmieniła i które dwa przepływy zweryfikowałeś. Ten zapis nie pozwala następnemu incydentowi zacząć się od tego samego założenia, że pfSense ignoruje sam siebie.