Store downloads mod VPN'en: vælg ruten ved forespørgslen

“Send de store downloads uden om VPN'en, og hold de små svar på den” lyder som en routingpolitik, og det er det ikke. En router beslutter ud fra information, der er tilgængelig i det øjeblik: adresser, porte, protokol, firewall-mærker, en identificeret strøm. Den endelige størrelse på svaret er ikke i det sæt, fordi den ikke er ankommet endnu, og når routeren kunne måle byte, transporterer den dem allerede. Hvis du vil styre efter opgave, skal beslutningen flyttes til et punkt, der kender opgaven, og tjeklisten nedenfor viser, om dit design har sådant et punkt.

Hvorfor en router ikke kan måle et svar

I det øjeblik en pakke skal have en rute, har routeren set højst de første få pakker af en strøm. Den kan fortælle, hvem der taler med hvem, over hvilken protokol, med hvilket mærke, og hvor mange byte der er passeret indtil nu. Byte indtil nu beskriver fortiden. Svarets størrelse er en egenskab ved et svar, der ikke er genereret endnu, og for opdelte eller streamede svar er den måske aldrig kendt på forhånd.

Selv protokollens egne metadata er svagere, end de ser ud. HTTP tillader svar, hvis længde ikke annonceres før kroppen, og en enkelt brugerhandling kan skabe mange forespørgsler, hvis samlede pris slet ikke ligner nogen enkelt header-værdi. At behandle en header som størrelsen på en opgave er en modelleringsfejl, før det er en routingfejl.

Tjek 1: findes der et beslutningspunkt, der kan vælge en rute?

Navngiv den komponent, der træffer valget, og navngiv derefter, hvad den ved i det øjeblik, den vælger. En opdatering, der henter fra et dokumenteret sæt værter, kender sit formål, før overførslen begynder. En downloadtjeneste, der konsulterer metadata og derefter åbner forespørgslen, kender opgaven, før forbindelsen findes. En samarbejdende proxy kan anvende politik på forespørgselsniveau eller cache svaret uden at foregive at være en router.

Hvis svaret er “gatewayen”, har tjeklisten allerede fejlet. En gateway kan klassificere kendte strømme efter destination, mærke eller klientsegment og sende dem ad en defineret rute fra den første pakke, hvilket ofte er godt nok til en godkendt opdatering og aldrig nok til en ukendt størrelse på svaret.

Tjek 2: hvad fortæller metadataene dig egentlig?

Applikationsbevidst styring er kun så god som de felter, den læser. Reglerne for svarlængde i HTTP-semantik tillader tilfælde, hvor længden ikke er tilgængelig i starten, og indholdskodninger gør under alle omstændigheder antallet af overførte byte forskelligt fra repræsentationens størrelse. Derfor vil en politik, der skifter rute, når en header krydser en tærskel, opføre sig inkonsekvent, og mest netop på de store overførsler, den skulle fange.

Det, applikationsmetadata kan understøtte, er en beslutning om en opgave: dette workflow er en bulk-synkronisering, dette er interaktivt, dette er en softwareopdatering fra en kendt oprindelse. Det er en politik skrevet i hensigtsbegreber, og den er stabil nok til at teste. “Dette svar bliver større end fyrre megabyte” er ikke den slags politik.

Tjek 3: findes strømmen allerede?

Routing kan ændre sig for en strøm uden at ændre forbindelsens identitet, og den forskel er værd at holde rede på. En TCP-forbindelse identificeres ved sine endpoint-adresser og porte, og pakkerne kan tage en anden rute, hvis routingtabellen ændres under dem. Det, der ikke kan ændre sig usynligt, er tilstanden for netværksadresseoversættelse: at flytte trafik til en anden udgang ændrer normalt den offentlige kildetuple, og den fjerne ende vil se en anden peer uden matchende tilstand.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Så den praktiske regel er, at et skift midt i en forbindelse fra en udgang til en anden er et nyt forhold, ikke en migrering. Hvis designet kræver, at den samme forbindelse fortsætter, måtte beslutningen træffes før det første SYN, og ingen pakkeregel, der tilføjes senere, kan rekonstruere det rent.

Tjek 4: er det reelle krav latenstid, ikke udgang?

Mange anmodninger om at “sende bulk-trafik et andet sted hen” er i virkeligheden klager over, at en stor overførsel får interaktivt arbejde til at føles langsomt. Det er et planlægningsproblem, og det har et planlægningssvar: fair kødannelse eller en understøttet båndbreddepolitik på den eksisterende rute forhindrer en bulk-strøm i at udsulte en chatbesked uden at flytte nogen af dem.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

At håndtere symptomet på denne måde holder udgangsbeslutningen, hvor sikkerhedspolitikken placerede den, og den kan rulles tilbage med én kommando. At ændre udgangen for en hel klasse af trafik er en politikændring med konsekvenser for godkendelse, logning og adgangsregler, så det bør ikke være det første værktøj, man griber til ved en klage over latenstid.

Hvis kravet reelt er en anden internetudgang, så sig det med de ord og implementér det ved en understøttet grænse: en ny forbindelse fra et godkendt workflow, eller en applikation, der åbner sin egen forespørgsel gennem en valgt udgang. Registrér derefter, hvilke opgaver der bruger hvilken udgang, så den næste person ikke skal udlede det af en routingtabel.

Behold tjeklisten i ændringsregistreringen: beslutningspunktet, feltet eller opgaven der driver det, om strømmen allerede findes, og om det målte symptom var latenstid eller udgang. Fire spørgsmål, og en politik, der besvarer alle fire, er en, du kan drive i stedet for at forsvare.