Groot aflaaie teenoor die VPN: kies die pad by die versoek

“Stuur die groot aflaaie om die VPN en hou die klein antwoorde daarop” klink na ’n roeteerbeleid, en dit is nie een nie. ’n Roeteerder besluit met inligting wat op daardie oomblik beskikbaar is: adresse, poorte, protokol, firewall-merke, ’n geïdentifiseerde vloei. Die uiteindelike grootte van ’n antwoord is nie in daardie stel nie, want dit het nog nie aangekom nie, en teen die tyd dat die roeteerder die grepe kon meet, dra dit hulle al. As jy volgens taak wil stuur, moet die besluit na ’n punt skuif wat die taak ken, en die kontrolelys hieronder is hoe jy uitvind of jou ontwerp so ’n punt het.

Waarom ’n roeteerder nie ’n antwoord se grootte kan bepaal nie

Op die oomblik dat ’n pakket ’n roete nodig het, het die roeteerder hoogstens die eerste paar pakkette van ’n vloei gesien. Dit kan jou vertel wie met wie praat, oor watter protokol, met watter merk, en hoeveel grepe tot dusver verby is. Grepe tot dusver beskryf die verlede. Die grootte van die antwoord is ’n eienskap van ’n antwoord wat nog nie geskep is nie, en vir verdeelde of stromende antwoorde is dit dalk nooit vooraf kenbaar nie.

Selfs die protokol se eie metadata is swakker as wat dit lyk. HTTP laat antwoorde toe waarvan die lengte nie voor die liggaam aangekondig word nie, en ’n enkele gebruikersaksie kan baie versoeke lewer waarvan die gesamentlike koste niks soos enige een kopwaarde is nie. Om ’n kop as die grootte van ’n taak te behandel, is ’n modelleringsfout voordat dit ’n roeteerfout is.

Kontrole 1: is daar ’n besluitpunt wat ’n pad kan kies?

Noem die komponent wat die keuse sal maak, en noem dan wat dit weet op die oomblik dat dit kies. ’n Opdaterer wat van ’n gedokumenteerde stel gashere laai, ken sy eie doel voordat die oordrag begin. ’n Aflaadiens wat metadata raadpleeg en dan die versoek oopmaak, ken die taak voordat die verbinding bestaan. ’n Samewerkende proxy kan beleid op versoekvlak toepas of die antwoord kas, sonder om voor te gee dat dit ’n roeteerder is.

As die antwoord “die gateway” is, het die kontrolelys al misluk. ’n Gateway kan bekende vloeie volgens bestemming, merk of kliëntsegment klassifiseer en hulle van die eerste pakket af op ’n bepaalde pad stuur, wat dikwels goed genoeg is vir ’n goedgekeurde opdaterer en nooit genoeg vir ’n onbekende antwoordgrootte nie.

Kontrole 2: wat vertel die metadata jou werklik?

Toepassingsbewuste sturing is net so goed soos die velde wat dit lees. Die reëls oor antwoordlengte in HTTP-semantiek laat gevalle toe waar die lengte nie aan die begin beskikbaar is nie, en inhoud-enkoderinge maak die oorgedraagde grepetelling in elk geval anders as die voorstelling se grootte. ’n Beleid wat van pad verander wanneer ’n kop ’n drempel oorsteek, sal dus inkonsekwent optree, en meestal juis op die groot oordragte wat dit veronderstel was om te vang.

Wat toepassingsmetadata wél kan ondersteun, is ’n besluit oor ’n taak: hierdie werkvloei is ’n grootmaat-sinkronisasie, hierdie een is interaktief, hierdie een is ’n sagteware-opdatering van ’n bekende oorsprong. Dit is ’n beleid in terme van bedoeling, en dit is stabiel genoeg om te toets. “Hierdie antwoord gaan groter as veertig megagrepe wees” is nie daardie soort beleid nie.

Kontrole 3: bestaan die vloei al?

Roetering kan vir ’n vloei verander sonder om die verbinding se identiteit te verander, en dit is ’n onderskeid wat die moeite werd is om reg te hou. ’n TCP-verbinding word deur sy eindpuntadresse en poorte geïdentifiseer, en die pakkette kan ’n ander pad neem as die roetertabel onder hulle verander. Wat nie onsigbaar kan verander nie, is die toestand van netwerkadresvertaling: om verkeer na ’n ander uitgang te skuif, verander gewoonlik die publieke brontupel, en die verre kant sal ’n ander portuur sien sonder passende toestand.

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

Die praktiese reël is dus dat ’n skuif van een uitgang na ’n ander midde-in die verbinding ’n nuwe verhouding is, nie ’n migrasie nie. As die ontwerp vereis dat dieselfde verbinding voortduur, moes die besluit voor die eerste SYN geneem word, en geen pakketreël wat later bygevoeg word, kan dit skoon herkonstrueer nie.

Kontrole 4: is die werklike vereiste traagheid, nie uitgang nie?

Baie versoeke om “stuur grootmaatverkeer elders” is eintlik klagtes dat ’n groot oordrag interaktiewe werk traag laat voel. Dit is ’n skeduleringsprobleem, en dit het ’n skeduleringsantwoord: regverdige touvorming of ’n ondersteunde bandwydtebeleid op die bestaande pad hou ’n grootmaatvloei daarvan weer om ’n boodskap te verhonger, sonder om enige van die twee te skuif.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Deur die simptoom so aan te spreek, bly die uitgangsbesluit waar die sekuriteitsbeleid dit gesit het, en dit is met een opdrag omkeerbaar. Om die uitgang vir ’n hele klas verkeer te verander, is ’n beleidsverandering met gevolge vir verifikasie, logboeke en toegangsreëls, so dit moet nie die eerste hulpmiddel wees waarna by ’n klagte oor traagheid gegryp word nie.

As die vereiste werklik ’n ander internetuitgang is, sê dit in daardie woorde en implementeer dit by ’n ondersteunde grens: ’n nuwe verbinding van ’n goedgekeurde werkvloei, of ’n toepassing wat sy eie versoek deur ’n gekose uitgang oopmaak. Teken dan aan watter take watter uitgang gebruik, sodat die volgende persoon dit nie uit ’n roetertabel hoef af te lei nie.

Hou die kontrolelys in die veranderingsrekord: die besluitpunt, die veld of taak wat dit dryf, of die vloei al bestaan, en of die gemete simptoom traagheid of uitgang was. Vier vrae, en ’n beleid wat al vier beantwoord, is een wat jy kan bedryf eerder as verdedig.