Kill switch se aktivira: što se događa s otvorenim TCP sesijama?

Tunel padne, kill switch se aktivira, a preuzimanje koje je bilo tri četvrtine gotovo ili se zamrzne ili odmah ne uspije. Ta dva ishoda dolaze iz različitih odluka o provođenju, a ne iz različitih razina zaštite. Odbačen paket ostavlja vezu u čekanju, dok je odbijeni paket zatvara i obavještava aplikaciju. Odlučiti koje ponašanje želite pitanje je dizajna, a testiranje je zasebna vježba.

Odbacivanje, odbijanje i resetiranje nisu isto

Pravilo vatrozida koje odbacuje promet baca paket i ne šalje ništa natrag, pa pošiljatelj nastavlja ponovno slati prema vlastitim mjeračima. Pravilo koje odbija s TCP resetom odmah zatvara vezu i aplikacija vidi pogrešku. Većina kill switcheva odbacuje, jer bi odbijanje otkrilo pravilo i jer odbacivanje nalikuje ponašanju mrtve mreže.

Blokiranje 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 operacijski sustav tvrdi da veza postoji. Čitajte dokumentirano provođenje umjesto da ga zaključujete iz poruke aplikacije, jer oba ponašanja izgledaju kao isključena mreža.

Što aplikacija radi dok prekid traje

TCP ponovno šalje s rastućim kašnjenjima, a zadani Linuxov proračun ponovnih pokušaja istječe otprilike za č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čunalu ponašaju različito tijekom jednog prekida.

Kad se tunel vrati, lokalni socket nije promijenjen, ali put možda jest. Nova javna izvorna adresa stvara različitu četvorku na poslužitelju, pa se vatrozid sa stanjem na drugoj strani više ne podudara sa sesijom. Veza je mrtva iako klijent nikada nije vidio pogrešku.

Odlučite je li oporavak potreban

Odaberite između dva ugovora. Ili sesija mora preživjeti kratki prekid, što zahtijeva stabilno adresiranje i poslužitelj koji čuva svoje stanje, ili se aplikacija mora čisto ponovno spojiti, što zahtijeva logiku ponovnih pokušaja koja je sigurna za ponavljanje. Bilo što između daje najgori ishod: klijent koji ponovno šalje ono što je poslužitelj već potvrdio ili onaj koji prijavljuje uspjeh za sesiju koju nitko ne može vidjeti.

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

Provjerite blokadu i oporavak odvojeno

Tretirajte zaštitu od curenja i preživljavanje sesije kao dva svojstva, jer prolazak jednog ne govori ništa o drugom. Sesija koja preživi nije dokaz da je izravni promet blokiran, a sesija koja umre nije dokaz da je svaka izravna 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 pri promatranju oporavka, kako duplicirano slanje ne bi postalo incident. Zabilježite način kvara koji ste stvarno vidjeli: što je aplikacija prikazala, je li socket preživio i kada se sam oporavio.

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