Klient se pokouší znovu připojit a z počítače nic nevychází, i když stejný profil minulý týden fungoval. Název koncového bodu se nyní překládá na jinou adresu a odchozí výjimka stále uvádí tu starou. Toto jediné zastaralé povolení stačí k tomu, aby se z fungujícího kill switch stal úplný výpadek, a v žádném ukazateli stavu na ploše to není vidět. Oprava je malý postup, ne jednorádková úprava.

Tunel se znovu připojí a pak už nic neodchází

Odchozí pravidlo, které uvádí cílovou adresu, je snímek, zatímco odpovědi DNS snímkem nejsou. Když poskytovatel adresu otočí, paket, který klient posílá k novému peerovi, neodpovídá ničemu a výchozí zákaz ho zahodí. Klient pak hlásí vypršení časového limitu, což vypadá spíš jako problém serveru než firewallu.

Připnout adresu, kterou vrátí veřejné vyhledávání, zajistí, že dnes to funguje a zítra je to rozbité. To je jednorázová úprava, ne politika údržby.

Popište výjimku, kterou skutečně zamýšlíte

Začněte tím, že si zapíšete čtyři hodnoty, které pravidlo potřebuje: schválený název koncového bodu nebo sadu adres, transport, cílový port a rozhraní, kterým paket odchází. Všechny čtyři jsou součástí povolení a kterákoli z nich může být špatně, i když pravidlo stále vypadá věrohodně. Pravidlo, které je správné ve třech z nich, selhává přesně stejně jako pravidlo, které je špatné ve všech čtyřech. Zapište je dřív, než napíšete příkaz, protože pravidlo je jen tak dobré, jako popis, který za ním stojí.

Příkaz níže ukazuje podobu pro jeden koncový bod IPv4 UDP na kabelovém uplinku. Nahraďte obě hodnoty těmi, které jste ověřili proti nasazení.

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

Toto povolení neopravňuje libovolné cíle na stejném portu, nevytváří naslouchající socket a nepokrývá TCP. Manuálová stránka UFW popisuje, jak adresa, rozhraní a protokol pravidlo zužují, a právě to zúžení je celý smysl.

Obnovte to jako jeden postup

Berte výjimku jako zdroj s vlastníkem a přechodem, ne jako příkaz, na který si někdo vzpomene. Nejprve získejte kandidáta z vlastního resolveru a inventáře koncových bodů nasazení a vědomě určete, jak se tento název překládá, než tunel existuje. Potom kandidáta ověřte proti zamýšlenému protokolu, portu a rodině adres, než se dotknete sady pravidel.

Nejprve nainstalujte nové úzké povolení a potvrďte, že se načetlo, protože poslat klienta na adresu, kterou firewall stále blokuje, vyvolá chybu, jež vypadá jako porucha serveru. Nesouvisející pravidla během změny nechte nedotčená.

Sledujte přechod klienta jeho podporovanou cestou opětovného připojení a potvrďte, kterou vzdálenou adresu si vybral. Aktualizace samotného DNS existující socket nepřesune a nastavení trvalosti koncového bodu může klienta držet u starého peera dlouho poté, co se záznam změnil.

Nakonec zastaralé povolení vědomě vyřaďte a povolte schválené překrývající se okno, dokud je stará relace ještě aktivní. Příliš brzké odstranění staré položky způsobí krátký výpadek; ponechání navždy zanechá povolení, které nikdo nedokáže vysvětlit.

Vyřaďte staré povolení vědomě

Odstranění je místo, kde leží většina rizika, protože staré pravidlo je jediná věc, která právě teď funguje. Pokud instalace kandidáta selhala, nepokračujte a nemažte položku, která stále nese provoz. Pokud selže samotné odstranění, poznamenejte zastaralé povolení jako zastaralé, místo abyste politiku prohlásili za aktuální.

Celou kontrolu zopakujte, když se uplink změní z Ethernetu na Wi-Fi, když se změní transport nebo když služba rotuje přes několik adres. Pravidlo specifické pro rozhraní má po změně sítě přestat odpovídat, a toto chování je správné, i když vypadá jako regrese.

Poté dokažte smlouvu neškodným provozem. Schválený koncový bod musí být během nastavení dosažitelný, chráněná aplikace musí po připojení fungovat a nesouvisející přímý provoz musí zůstat během výpadku blokovaný. Zahrňte obě rodiny adres a jeden záměrně neúspěšný pokus o aktualizaci, protože spojení, které uspěje po jediné úpravě připnuté adresy, nedokazuje ani jeden z těchto případů.

Související články