A kliens újra próbál csatlakozni, és semmi sem hagyja el a gépet, pedig ugyanaz a profil múlt héten még működött. A végpont hosztneve most más címre oldódik fel, a kimenő kivétel pedig még a régit nevezi meg. Ez az egyetlen elavult engedély elég ahhoz, hogy egy működő kill switchet teljes kieséssé változtasson, és semmilyen állapotjelző nem mutatja az asztalon. A javítás egy kis munkafolyamat, nem egysoros módosítás.

Az alagút újracsatlakozik, aztán már semmi sem megy ki

Az a kimenő szabály, amely megnevez egy célcímet, pillanatkép, a DNS-válaszok viszont nem azok. Amikor a szolgáltató átforgat egy címet, a kliens által az új peer felé küldött csomag semmihez sem illeszkedik, és az alapértelmezett tiltás eldobja. A kliens ezután időtúllépésről számol be, ami inkább szerverhibának, mint tűzfalhibának tűnik.

Egy nyilvános lekérdezés által visszaadott cím rögzítése a mait működőképessé teszi, a holnapot pedig elrontja. Ez egyszeri módosítás, nem karbantartási szabályzat.

Írja le, milyen kivételt is akar valójában

Kezdje annak a négy értéknek a felírásával, amelyre a szabálynak szüksége van: a jóváhagyott végpontnév vagy címhalmaz, a transzport, a célport és az az interfész, amelyen a csomag kilép. Mind a négy része az engedélynek, és bármelyikük hibás lehet úgy, hogy a szabály még hihetőnek látszik. Egy háromban helyes szabály pontosan ugyanúgy meghiúsul, mint egy mind a négyben hibás szabály. Írja fel őket, mielőtt beírja a parancsot, mert egy szabály csak annyit ér, amennyit a mögötte álló leírás.

Az alábbi parancs egy IPv4 UDP-végpont formáját mutatja vezetékes uplink esetén. Cserélje ki mindkét értéket arra, amelyeket a telepítéshez képest ellenőrzött.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Ez az engedély nem tesz lehetővé tetszőleges célokat ugyanazon a porton, nem hoz létre figyelőt, és nem fedi le a TCP-t. Az UFW kézikönyv oldala leírja, hogyan szűkíti a szabályt a cím, az interfész és a protokoll, és éppen ez a szűkítés a lényeg.

Frissítse egyetlen munkafolyamatként

Kezelje a kivételt olyan erőforrásként, amelynek gazdája és átmenete van, ne olyan parancsként, amelyre valaki emlékszik. Először szerezzen jelöltet a telepítés saját feloldójából és végpontleltárából, és tudatosan határozza meg, hogyan oldódik fel ez a név, mielőtt az alagút létezne. Ezután érvényesítse a jelöltet a tervezett protokoll, port és címcsalád ellen, mielőtt a szabálykészlethez nyúl.

Először telepítse az új szűk engedélyt, és erősítse meg, hogy betöltődött, mert ha a klienst olyan cím használatára kéri, amelyet a tűzfal még blokkol, olyan hibát kap, amely szerverhibának látszik. A változtatás alatt hagyja érintetlenül a nem kapcsolódó szabályokat.

Figyelje meg a kliens átmenetét a támogatott újracsatlakozási útvonalon, és erősítse meg, melyik távoli címet választotta. A DNS önmagában történő frissítése nem mozgat egy meglévő socketet, és a végpont-megőrzési beállítás miatt a kliens jóval a rekord megváltozása után is a régi peernen maradhat.

Végül tudatosan vonja vissza az elavult engedélyt, engedve a jóváhagyott átfedési ablakot, amíg egy régi munkamenet még aktív. A régi bejegyzés túl korai eltávolítása rövid kiesést okoz; örökre meghagyva olyan engedély marad, amelyet senki sem tud megmagyarázni.

Tudatosan vonja vissza a régi engedélyt

Az eltávolítás az a pont, ahol a legtöbb kockázat van, mert a régi szabály az egyetlen, ami jelenleg működik. Ha a jelölt telepítése meghiúsult, ne folytassa, és ne törölje azt a bejegyzést, amely még forgalmat hordoz. Ha maga az eltávolítás hiúsul meg, az elavult engedélyt elavultként jegyezze fel ahelyett, hogy a szabályzatot aktuálisnak nyilvánítaná.

Ismételje meg a teljes átvizsgálást, amikor az uplink Ethernetről Wi-Fi-re vált, amikor a transzport változik, vagy amikor egy szolgáltatás több cím között forog. Az interfészspecifikus szabálynak a hálózatváltás után meg kell szűnnie illeszkedni, és ez a viselkedés helyes, még ha regressziónak is látszik.

Ezután ártalmatlan forgalommal bizonyítsa a szerződést. A jóváhagyott végpontnak a beállítás alatt elérhetőnek kell lennie, a védett alkalmazásnak csatlakozás után működnie kell, és a nem kapcsolódó közvetlen forgalomnak kiesés alatt blokkolva kell maradnia. Foglalja bele mindkét címcsaládot és egy szándékosan sikertelen frissítési kísérletet, mert az a kapcsolat, amely egyetlen rögzített cím módosítása után jön létre, egyik esetet sem bizonyítja.

Kapcsolódó cikkek