Punte TAP virtuală în pfSense: trei locuri unde un cadru poate muri

Dezactivați o regulă pe interfața LAN, cadrul dispare în continuare, iar concluzia este că pfSense își ignoră propriul firewall. De obicei s-a întâmplat ca un alt proprietar să fi luat decizia: puntea însăși, interfața membru sau comutatorul virtual din afara oaspetelui. Fiecare are propriul control și propriul jurnal.

Merită să separați cele trei granițe de mai jos înainte de a schimba o setare, deoarece dezactivarea uneia nu poate compensa cealaltă.

Un cadru, trei proprietari de politică

Un cadru de la un client TAP intră prin dispozitivul de tunel, traversează puntea pfSense, iese printr-un membru LAN și apoi trece printr-un comutator virtual înainte de a ajunge oriunde. În interiorul oaspetelui, filtrarea poate avea loc pe punte sau pe interfețele membre, iar care este activă este o alegere de configurare, nu o proprietate fixă. În afara oaspetelui, hipervizorul decide dacă acel adaptor virtual poate transmite cadre cu un MAC sursă pe care nu îl deține. O eliminare în oricare dintre acele puncte arată identic din perspectiva clientului.

Notați traseul dorit înainte de a investiga: membru de tunel, punte, membru LAN, comutator virtual, destinație. Apoi întrebați care proprietar de pe acel traseu ar fi văzut cadrul.

Care control pfSense filtrează

pfSense documentează două sysctl pentru aceasta, unul pentru filtrarea pe membrii punții și unul pentru filtrarea pe puntea însăși, iar cel puțin unul dintre ele trebuie să rămână activat. Filtrarea la nivel de punte se aplică traficului care sosește prin membrii punții, deci este de intrare ca orientare, nu simetrică. Citiți regulile pe interfața care filtrează efectiv, deoarece o regulă plasată pe un membru fără rol de filtrare nu face absolut nimic. Documentația de filtrare a punții explică proprietatea.

O interfață membru fără adresă IP nu are o macro de adresă sau subrețea proprie, așa că o regulă scrisă împotriva acelei macro poate descrie altceva decât LAN-ul dorit. Folosiți obiecte de rețea atribuite deliberat în locul macro-urilor de confort.

Un fragment nu este un cadru

Cadrele Ethernet transportă pachete IP, iar un pachet IP poate fi un fragment dintr-o datagramă mai mare, așa că cele două cuvinte nu sunt interschimbabile. Există și un pachet interior în tunel și un pachet de transport exterior în afara lui, iar o defecțiune poate aparține oricăruia. Un ping mic exersează o singură cale prin acel stivă și nu dovedește nimic despre un transfer mare. Comparați schimbul care eșuează la două granițe adiacente și citiți motivul eliminării înainte de a da vina pe o regulă.

Dacă fragmentele dispar, răspunsul este o corecție limitată sau o investigație a dimensiunii pachetului, nu o decizie de a dezactiva filtrarea în totalitate.

Hipervizorul are propria decizie de admitere

Un oaspete care puntează trafic pentru alte mașini emite cadre ale căror adrese MAC sursă nu sunt ale adaptorului propriu, iar multe comutatoare virtuale tratează asta ca falsificare dacă grupul de porturi nu permite. Permiterea acelei transmisii și permiterea adaptorului de a primi fiecare cadru sunt controale separate, iar activarea ambelor peste tot este o schimbare mult mai mare decât cere problema. Stabiliți ce cadre trebuie să primească și să emită puntea, apoi acordați doar acel comportament la granița care îl deține. Păstrați accesul la consolă înainte de a schimba o punte administrată de la distanță.

Restabilirea conectivității este jumătate din test; cealaltă jumătate este confirmarea că un flux care ar trebui să rămână blocat este încă blocat.

Notați care proprietar a filtrat, ce control s-a schimbat și ce două fluxuri ați verificat. Acea notă împiedică următorul incident să înceapă cu aceeași presupunere că pfSense se ignoră pe sine.