Zaštitni prekidač se aktivira: šta se dešava s otvorenim TCP sesijama?

Tunel padne, zaštitni prekidač se aktivira, a preuzimanje koje je bilo tri četvrtine gotovo ili se zamrzne ili odmah propadne. Ta dva ishoda dolaze iz različitih odluka o provođenju, a ne iz različitih nivoa zaštite. Odbačen paket ostavlja vezu da čeka, dok je odbijeni paket zatvara i obavještava aplikaciju. Odlučiti kakvo ponašanje želite jeste pitanje dizajna, a testirati ga je odvojeni zadatak.

Odbačeno, odbijeno i resetovano nisu isto

Pravilo firewall-a koje odbacuje saobraćaj baca paket i ne vraća ništa, pa pošiljalac nastavlja ponovo slati po vlastitim tajmerima. Pravilo koje odbija TCP resetom zatvara vezu odmah i aplikacija vidi grešku. Većina zaštitnih prekidača odbacuje, jer bi odbijanje otkrilo politiku i jer odbacivanje liči na ponašanje mrtve mreže.

Blokiranje također nije isto što i zatvaranje socketa. Aplikacija još drži deskriptor u uspostavljenom stanju, a nedostaju samo paketi. Zato stranica može minutama stajati na spinneru dok operativni sistem tvrdi da veza postoji. Čitajte dokumentovano provođenje umjesto da ga zaključujete iz poruke aplikacije, jer oba ponašanja izgledaju kao da je mreža pala.

Šta aplikacija radi dok prekid traje

TCP ponovo šalje s rastućim kašnjenjima, a zadani Linux budžet pokušaja ističe negdje oko četvrt sata, a ne u sekundama. Do tada socket nije ni korisno otvoren ni zatvoren. Aplikacije s vlastitim keepalive-ima ili vremenskim ograničenjima zahtjeva često odustaju ranije, zato se dva programa na istom računaru ponašaju različito tokom jednog ispada.

Kada se tunel vrati, lokalni socket je nepromijenjen, ali put možda nije. Nova javna izvorna adresa stvara drugačiju četvorku na serveru, pa stateful firewall na suprotnoj strani više ne odgovara sesiji. Veza je mrtva iako klijent nikada nije vidio grešku.

Odlučite je li oporavak potreban

Odaberite između dva ugovora. Ili sesija mora preživjeti kratak prekid, što traži stabilno adresiranje i server koji čuva svoje stanje, ili se aplikacija mora čisto ponovo povezati, što traži logiku ponovnih pokušaja sigurnu za ponavljanje. Sve između daje najgori ishod: klijent koji ponovo šalje ono što je server već upisao, ili onaj koji prijavljuje uspjeh za sesiju koju niko ne vidi.

Stabilno adresiranje je dio koji ljudi zaboravljaju, jer ponovno povezivanje koje sleti na drugu javnu adresu poništava stanje na strani servera čak i kada socket klijenta izgleda zdravo. Zapišite koji od dva ugovora vrijedi za svaku aplikaciju, jer se rijetko svi poklapaju.

Testirajte blokadu i oporavak odvojeno

Tretirajte zaštitu od curenja i preživljavanje sesije kao dvije osobine, jer prolazak jedne ne govori ništa o drugoj. Sesija koja preživi nije dokaz da je direktni saobraćaj blokiran, a sesija koja umre nije dokaz da je svaka direktna ruta blokirana.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Koristite bezopasnu testnu radnju kada posmatrate oporavak, kako duplo slanje ne bi postalo sam incident. Zabilježite način otkaza koji ste zaista vidjeli: šta je aplikacija prikazala, da li je socket preživio i kada se sam oporavio.

Zapišite očekivano ponašanje pored pravila provođenja i datirajte ga. Sljedeća osoba koja promijeni to pravilo mora znati koji je od dva ugovora implementacija obećala.