Ura virtuale TAP e pfSense: tre vende ku një kornizë mund të vdesë

Çaktivizoni një rregull në ndërfaqen LAN, korniza vazhdon të zhduket, dhe përfundimi është se pfSense injoron murin e vet të zjarrit. Ajo që zakonisht ka ndodhur është se një pronar tjetër mori vendimin: vetë ura, ndërfaqja anëtare ose komutatori virtual jashtë mysafirit. Secili ka kontrollin e vet dhe regjistrin e vet.

Tre kufijtë më poshtë ia vlen të ndahen përpara se të ndryshoni një cilësim, sepse çaktivizimi i njërit nuk mund të kompensojë tjetrin.

Një kornizë, tre pronarë politike

Një kornizë nga një klient TAP hyn përmes pajisjes së tunelit, kalon urën pfSense, del përmes një anëtari LAN dhe më pas kalon një komutator virtual përpara se të arrijë ndonjë gjë. Brenda mysafirit, filtrimi mund të ndodhë në urë ose në ndërfaqet anëtare, dhe cila është aktive është zgjedhje konfigurimi dhe jo veti fikse. Jashtë mysafirit, hipervizori vendos nëse ai përshtatës virtual mund të transmetojë korniza me një MAC burim që nuk e zotëron. Një rënie në cilindo nga ato pika duket identike nga ana e klientit.

Shkruani rrugën e synuar përpara se të hetoni: anëtari i tunelit, ura, anëtari LAN, komutatori virtual, destinacioni. Pastaj pyesni cili pronar në atë rrugë do ta kishte parë kornizën.

Cili kontroll i pfSense po filtron

pfSense dokumenton dy sysctl për këtë, një për filtrimin në anëtarët e urës dhe një për filtrimin në vetë urën, dhe të paktën njëri prej tyre duhet të mbetet i aktivizuar. Filtrimi në nivel ure zbatohet për trafikun që vjen përmes anëtarëve të urës, prandaj është hyrës nga orientimi dhe jo simetrik. Lexoni rregullat në ndërfaqen që filtron vërtet, sepse një rregull i vendosur në një anëtar pa rol filtrim nuk bën absolutisht asgjë. Dokumentacioni i filtrimit të urës shpjegon pronësinë.

Një ndërfaqe anëtare pa adresë IP nuk ka makro adrese ose nënrrjeti të vetën, kështu që një rregull i shkruar kundër atij makro mund të përshkruajë diçka tjetër nga LAN-i që kishit në mendje. Përdorni objekte rrjeti të caktuara me qëllim në vend të makrove të komoditetit.

Një fragment nuk është kornizë

Kornizat Ethernet mbajnë paketa IP, dhe një paketë IP mund të jetë fragment i një datagrami më të madh, prandaj dy fjalët nuk janë të këmbyeshme. Ka gjithashtu një paketë të brendshme brenda tunelit dhe një paketë transporti të jashtme jashtë tij, dhe dështimi mund t'i përkasë qoftë njërës. Një ping i vogël provon një rrugë përmes atij stack dhe nuk dëshmon asgjë për një transferim të madh. Krahasoni shkëmbimin që dështon në dy kufij të afërt dhe lexoni arsyen e rënies përpara se të fajësoni një rregull.

Nëse fragmentet zhduken, përgjigjja është një korrigjim i kufizuar ose një hetim i madhësisë së paketës, jo një vendim për të çaktivizuar filtrimin plotësisht.

Hipervizori ka vendimin e vet të pranimit

Një mysafir që uron trafikun për makineri të tjera lëshon korniza, adresat MAC burim të të cilave nuk janë të përshtatësit të vet, dhe shumë komutatorë virtualë e trajtojnë atë si falsifikim nëse grupi i porteve nuk e lejon. Lejimi i asaj transmetimi dhe lejimi i përshtatësit të marrë çdo kornizë janë kontroll të veçantë, dhe aktivizimi i të dyjave kudo është një ndryshim shumë më i madh sesa kërkon problemi. Përcaktoni cilat korniza ura duhet të marrë dhe duhet të lëshojë, pastaj jepni vetëm atë sjellje në kufirin që e zotëron. Mbani aksesin në konsolë përpara se të ndryshoni një urë të menaxhuar në distancë.

Rivendosja e lidhjes është gjysma e testit; gjysma tjetër është konfirmimi se një fluks që duhet të mbetet i bllokuar është ende i tillë.

Regjistroni cili pronar filtroi, cili kontroll ndryshoi dhe cilat dy flukse verifikuat. Ai regjistrim pengon incidentin e ardhshëm të fillojë me të njëjtin supozim se pfSense injoron vetveten.