Stórar niðurhalanir gegn VPN: veldu leiðina við beiðnina

„Sendu stóru niðurhalanirnar fram hjá VPN og haltu litlu svörunum á því“ hljómar eins og beiningastefna, en er það ekki. Beinir ákveður með upplýsingum sem eru tiltækar á því augnabliki: vistföngum, portum, samskiptareglum, firewall-merkjum, auðkenndu flæði. Endanleg stærð svars er ekki í því mengi, því það er ekki komið enn, og þegar beinirinn gæti mælt bætin er hann þegar að flytja þá. Ef þú vilt stýra eftir verkefni verður ákvörðunin að flytjast á punkt sem þekkir verkefnið, og gátlistinn hér að neðan sýnir hvort hönnunin þín hefur slíkan punkt.

Hvers vegna beinir getur ekki mælt svar

Á því augnabliki sem pakki þarf leið hefur beinirinn séð að hámarki fyrstu pakkana í flæði. Hann getur sagt hver talar við hvern, á hvaða samskiptareglum, með hvaða merki og hversu margir bætir hafa farið hingað til. Bætir hingað til lýsa fortíðinni. Stærð svarsins er eiginleiki svars sem hefur ekki verið búið til, og hjá skiptum eða streymisvörum er það kannski aldrei þekkt fyrirfram.

Jafnvel eigin lýsigögn samskiptareglnanna eru veikari en þau virðast. HTTP leyfir svör þar sem lengdin er ekki tilkynnt fyrir líkamann, og ein aðgerð notanda getur búið til margar beiðnir sem samanlögð kostnaður þeirra líkist engu einu hausgildi. Að meðhöndla haus sem stærð verkefnis er líkanavilla áður en hún er beiningavilla.

Athugun 1: er ákvörðunarpunktur sem getur valið leið?

Nefndu íhlutinn sem mun velja, og nefndu svo hvað það veit á valstundu. Uppfærsla sem sækir frá skjalfestu safni hýsla veit tilgang sinn áður en flutningurinn hefst. Niðurhalsþjónusta sem skoðar lýsigögn og opnar svo beiðnina veit verkefnið áður en tengingin verður til. Samvirkur proxy getur beitt stefnu á beiðnistigi eða skyggt á svarið án þess að þykjast vera beinir.

Ef svarið er „gáttin“ hefur gátlistinn þegar mistekist. Gátt getur flokkað þekkt flæði eftir áfangastað, merki eða biðlara hluta og sent þau eftir skilgreindri leið frá fyrsta pakka, sem er oft nóg fyrir samþykkta uppfærslu og aldrei nóg fyrir óþekkta svarstærð.

Athugun 2: hvað segja lýsigögnin þér í raun?

Forritavitund stýring er aðeins eins góð og reitirnir sem hún les. Reglur um svaralengd í merkingarfræði HTTP leyfa tilvik þar sem lengdin er ekki tiltæk í byrjun, og efnisþjöppun gerir fjölda fluttra bæta engu að síður frábrugðinn stærð framsetningarinnar. Þess vegna mun stefna sem skiptir um leið þegar haus fer yfir þröskuld haga sér ósamkvæmt, og aðallega einmitt á stóru flutningunum sem hún átti að grípa.

Það sem lýsigögn forrits geta stutt er ákvörðun um verkefni: þetta vinnuferli er fjöldasamstilling, þetta er gagnvirkt, þetta er hugbúnaðaruppfærsla frá þekktum uppruna. Það er stefna skrifuð í skilmálum ætlunar, og hún er nógu stöðug til að prófa. „Þetta svar verður stærra en fjörutíu megabæt“ er ekki slík stefna.

Athugun 3: er flæðið þegar til?

Beiningar geta breyst fyrir flæði án þess að auðkenni tengingarinnar breytist, og þann mun er vert að halda skýrum. TCP-tenging er auðkennd með vistföngum og portum enda sinna, og pakkarnir geta farið aðra leið ef beiningatöflan breytist undir þeim. Það sem getur ekki breyst ósýnilega er staða þýðingar netfanga: að færa umferð á annan útgang breytir venjulega opinberu upprunatúplinu, og fjarlægi endinn mun sjá annan jafningja án samsvarandi stöðu.

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

Svo hagnýta reglan er að færsla um miðja tengingu frá einum útgangi á annan er nýtt samband, ekki flutningur. Ef hönnunin krefst þess að sama tenging haldi áfram þurfti ákvörðunin að vera tekin fyrir fyrsta SYN, og engin pakkaregla sem bætt er við síðar getur endurgerð hana hreint.

Athugun 4: er raunverulega krafan seinkun, ekki útgangur?

Mjög margar beiðnir um að „senda fjöldaumferð annað“ eru í raun kvartanir yfir því að stór flutningur láti gagnvirkt starf virðast hægt. Það er röðunarverkefni, og það hefur röðunarsvar: sanngjörn biðröð eða studd bandvíddarstefna á núverandi leið kemur í veg fyrir að fjöldaflæði svelti spjallskilaboð án þess að færa hvort tveggja.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Að takast á við einkennið svona heldur útgangsákvörðuninni þar sem öryggisstefnan setti hana, og hún er afturkræf með einni skipun. Að breyta útganginum fyrir heilan flokk umferðar er stefnubreyting með afleiðingum fyrir auðkenningu, skráningu og aðgangsreglur, svo hún ætti ekki að vera fyrsta verkfærið við kvörtun um seinkun.

Ef krafan er sannarlega annar internetútgangur, segðu það með þeim orðum og innleiddu það við studda mörk: ný tenging frá samþykktu vinnuferli, eða forrit sem opnar eigin beiðni um valinn útgang. Skráðu svo hvaða verkefni nota hvaða útgang, svo næsta manneskja þurfi ekki að álykta það úr beiningatöflu.

Haltu gátlistanum í breytingaskránni: ákvörðunarpunkturinn, reiturinn eða verkefnið sem knýr hann, hvort flæðið er þegar til og hvort mælda einkennið var seinkun eða útgangur. Fjórar spurningar, og stefna sem svarar öllum fjórum er ein sem þú getur rekið í stað þess að verja.