Kill Switch Activate: Wat Gebeur met Oop TCP-Sessies?

Die tonnel val weg, die kill switch tree in werking, en ’n aflaai wat driekwart voltooi was, vries óf misluk onmiddellik. Dié twee uitkomste kom van verskillende handhawingskeuses, nie van verskillende vlakke van beskerming nie. ’n Pakkie wat laat val word, laat die verbinding wag, terwyl ’n verwerpte een dit sluit en die toepassing inlig. Om te besluit watter gedrag jy wil hê, is ’n ontwerpvraag, en om dit te toets is ’n aparte oefening.

Laat val, verwerp en reset is nie dieselfde nie

’n Vuurreël wat verkeer laat val, gooi die pakkie weg en stuur niks terug nie, so die sender bly op sy eie tydhouers herstuur. ’n Reël wat met ’n TCP-reset verwerp, sluit die verbinding onmiddellik en die toepassing sien ’n fout. Die meeste kill switches laat val, want ’n verwerping sou die beleid openbaar maak en omdat laat val soos ’n dooie netwerk lyk.

Blokkering is ook nie dieselfde as om die socket te sluit nie. Die toepassing hou steeds ’n descriptor in ’n gevestigde toestand, en net die pakkies ontbreek. Dis hoekom ’n bladsy minute lank op ’n spinner kan sit terwyl die bedryfstelsel volhou die verbinding bestaan. Lees die gedokumenteerde handhawing eerder as om dit uit die toepassing se boodskap af te lei, want albei gedrag lyk soos ’n netwerk wat af is.

Wat die toepassing doen terwyl die gaping duur

TCP herstuur met toenemende vertragings, en Linux se verstek-herprobeerbegroting verstryk iewers rondom ’n kwartier eerder as in sekondes. Tot dan is die socket nie nuttig oop of gesluit nie. Toepassings met hul eie keepalives of versoektydperke gee dikwels vroeër op, en daarom gedra twee programme op dieselfde masjien hulle anders tydens een onderbreking.

Wanneer die tonnel terugkom, is die plaaslike socket onveranderd, maar die pad is dalk nie. ’n Nuwe publieke bronadres lewer ’n ander vier-tupel by die bediener, so ’n toestandvolle vuurmuur aan die ander kant pas nie meer by die sessie nie. Die verbinding is dood al het die kliënt nooit ’n fout gesien nie.

Besluit of herstel nodig is

Kies tussen twee kontrakte. Óf die sessie moet ’n kort gaping oorleef, wat stabiele adressering en ’n bediener wat sy toestand hou vereis, óf die toepassing moet skoon weer koppel, wat herprobeerlogika vereis wat veilig is om te herhaal. Enigiets tussenin lewer die slegste uitkoms: ’n kliënt wat weer instuur wat die bediener reeds toegesê het, of een wat sukses rapporteer vir ’n sessie wat niemand kan sien nie.

Stabiele adressering is die deel wat mense vergeet, want ’n herkoppeling wat op ’n ander publieke adres beland, maak bedienerkant-toestand ongeldig selfs wanneer die kliënt se socket gesond lyk. Skryf neer watter van die twee kontrakte op elke toepassing van toepassing is, want hulle stem selde almal ooreen.

Toets die blokkade en die herstel afsonderlik

Behandel lekbeskerming en sessieoorlewing as twee eienskappe, want om een te slaag sê niks oor die ander nie. ’n Sessie wat oorleef is nie bewys dat direkte verkeer geblokkeer is nie, en ’n sessie wat sterf is nie bewys dat elke direkte roete geblokkeer is nie.

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'

Gebruik ’n onskadelike toetsbewerking wanneer jy herstel waarneem, sodat ’n duplikaat-inzending nie die voorval word nie. Teken die foutmodus aan wat jy werklik gesien het: wat die toepassing gewys het, of die socket oorleef het, en wanneer dit vanself herstel het.

Skryf die verwagte gedrag langs die handhawingsreël en dateer dit. Die volgende persoon wat daardie reël verander, moet weet watter van die twee kontrakte die ontplooiing belowe het.