Store nedlastinger mot VPN-en: velg veien ved forespørselen

«Send de store nedlastingene utenom VPN-en og hold de små svarene på den» høres ut som en ruterpolitikk, og det er det ikke. En ruter bestemmer ut fra informasjonen som er tilgjengelig i øyeblikket: adresser, porter, protokoll, brannmurmarkeringer, en identifisert strøm. Den endelige størrelsen på et svar er ikke i det settet, fordi det ikke har ankommet ennå, og når ruteren kunne måle bytene, frakter den dem allerede. Hvis du vil styre etter oppgave, må beslutningen flyttes til et punkt som kjenner oppgaven, og sjekklisten nedenfor viser om designet ditt har et slikt punkt.

Hvorfor en ruter ikke kan måle et svar

I det øyeblikket en pakke trenger en rute, har ruteren sett høyst de første få pakkene i en strøm. Den kan si hvem som snakker med hvem, over hvilken protokoll, med hvilken markering, og hvor mange byte som har passert så langt. Byte så langt beskriver fortiden. Størrelsen på svaret er en egenskap ved et svar som ikke er generert ennå, og for oppdelte eller strømmende svar er den kanskje aldri kjent på forhånd.

Selv protokollens egne metadata er svakere enn de ser ut. HTTP tillater svar der lengden ikke kunngjøres før kroppen, og én enkelt brukerhandling kan produsere mange forespørsler der den samlede kostnaden ikke ligner noen enkelt header-verdi. Å behandle en header som størrelsen på en oppgave er en modelleringsfeil før det er en ruterfeil.

Sjekk 1: finnes det et beslutningspunkt som kan velge en vei?

Navngi komponenten som skal gjøre valget, og navngi deretter hva den vet i det øyeblikket den velger. En oppdatering som henter fra et dokumentert sett verter, kjenner formålet sitt før overføringen starter. En nedlastingstjeneste som sjekker metadata og deretter åpner forespørselen, kjenner oppgaven før forbindelsen finnes. En samarbeidende proxy kan bruke politikk på forespørselsnivå eller cache svaret uten å late som den er en ruter.

Hvis svaret er «gatewayen», har sjekklisten allerede feilet. En gateway kan klassifisere kjente strømmer etter destinasjon, markering eller klientsegment og sende dem nedover en definert vei fra første pakke, noe som ofte er nok for en godkjent oppdatering og aldri nok for en ukjent svarsstørrelse.

Sjekk 2: hva forteller metadataene deg egentlig?

Applikasjonsbevisst styring er bare så god som feltene den leser. Reglene for svarlengde i HTTP-semantikk tillater tilfeller der lengden ikke er tilgjengelig ved start, og innholdskodinger gjør uansett antall overførte byte forskjellig fra representasjonens størrelse. Derfor vil en politikk som bytter vei når en header krysser en terskel, oppføre seg inkonsekvent, og mest nettopp på de store overføringene den skulle fange.

Det applikasjonsmetadata kan støtte, er en beslutning om en oppgave: denne arbeidsflyten er en massiv synkronisering, denne er interaktiv, denne er en programvareoppdatering fra en kjent opprinnelse. Det er en politikk skrevet i intensjonsbegreper, og den er stabil nok til å testes. «Dette svaret blir større enn førti megabyte» er ikke den slags politikk.

Sjekk 3: finnes strømmen allerede?

Ruting kan endre seg for en strøm uten å endre forbindelsens identitet, og den forskjellen er verdt å holde rede på. En TCP-forbindelse identifiseres av endepunktsadressene og portene sine, og pakkene kan ta en annen vei hvis rutetabellen endres under dem. Det som ikke kan endre seg usynlig, er tilstanden til nettverksadresseoversettelsen: å flytte trafikk til en annen utgang endrer vanligvis den offentlige kildetuppelen, og den fjerne enden vil se en annen peer uten samsvarende 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 regelen er at en flytting midt i en forbindelse fra én utgang til en annen er et nytt forhold, ikke en migrering. Hvis designet krever at den samme forbindelsen fortsetter, måtte beslutningen tas før den første SYN, og ingen pakkeregel som legges til senere kan rekonstruere den rent.

Sjekk 4: er det egentlige kravet latenstid, ikke utgang?

Svært mange forespørsler om å «sende bulk-trafikk et annet sted» er egentlig klager over at en stor overføring får interaktivt arbeid til å føles tregt. Det er et planleggingsproblem, og det har et planleggingssvar: rettferdig køing eller en støttet båndbreddepolitikk på den eksisterende veien hindrer en bulkstrøm i å sulte en chatmelding uten å flytte noen av dem.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Å håndtere symptomet på denne måten holder utgangsbeslutningen der sikkerhetspolitikken plasserte den, og den kan rulles tilbake med én kommando. Å endre utgangen for en hel klasse trafikk er en politikkendring med konsekvenser for autentisering, logging og tilgangsregler, så det bør ikke være det første verktøyet ved en klage på latenstid.

Hvis kravet virkelig er en annen internettutgang, si det med de ordene og implementer det ved en støttet grense: en ny forbindelse fra en godkjent arbeidsflyt, eller en applikasjon som åpner sin egen forespørsel gjennom en valgt utgang. Registrer deretter hvilke oppgaver som bruker hvilken utgang, slik at neste person ikke må utlede det fra en rutetabell.

Behold sjekklisten i endringsoppføringen: beslutningspunktet, feltet eller oppgaven som driver det, om strømmen allerede finnes, og om det målte symptomet var latenstid eller utgang. Fire spørsmål, og en politikk som svarer på alle fire, er en du kan drive i stedet for å forsvare.