Deskarga handiak VPNaren aurka: aukeratu bidea eskaeran

«Bidali deskarga handiak VPNaren inguruan eta eutsi erantzun txikiak haren gainean» bideratze-politika bat dirudi, eta ez da. Bideratzaileak une hartan eskuragarri dagoen informazioarekin erabakitzen du: helbideak, atakak, protokoloa, firewall-markak, identifikatutako fluxu bat. Erantzun baten azken tamaina ez dago multzo horretan, oraindik heldu ez delako, eta bideratzaileak byteak neurtu ahal izateko garaian jada haiek garraiatzen ari da. Zereginaren arabera gidatu nahi baduzu, erabakiak zeregina ezagutzen duen puntu batera joan behar du, eta beheko zerrendak erakusten du zure diseinuak puntu hori duen ala ez.

Zergatik ezin duen bideratzaile batek erantzun bat neurtu

Pakete batek bide bat behar duen unean, bideratzaileak fluxu baten lehen paketeak soilik ikusi ditu gehienez. Esan dezake nor norekin ari den hitz egiten, zein protokolorekin, zein markarekin eta zenbat byte igaro diren orain arte. Orain arteko byteek iragana deskribatzen dute. Erantzunaren tamaina oraindik sortu gabeko erantzun baten propietatea da, eta erantzun zatituetan edo streaming bidezkoetan agian ez da inoiz aldez aurretik ezagutzen.

Protokoloaren beraren metadatuak ere itxura baino ahulagoak dira. HTTPk onartzen ditu gorputza baino lehen luzera iragartzen ez duten erantzunak, eta erabiltzaile-ekintza bakar batek hainbat eskaera sor ditzake, zeinen kostu bateratuak ez baitu inongo goiburu-balio baten antzik. Goiburu bat zeregin baten tamaintzat hartzea modelatze-errore bat da, bideratze-errore bat baino lehen.

1. egiaztapena: badago bidea aukera dezakeen erabaki-punturik?

Izenda ezazu hautaketa egingo duen osagaia, eta gero aipa itzazu hautaketa egitean dakienak. Host-multzo dokumentatu batetik deskargatzen duen eguneratzaileak bere helburua ezagutzen du transferentzia hasi aurretik. Metadatuak kontsultatu eta gero eskaera irekitzen duen deskarga-zerbitzuak zeregina ezagutzen du konexioa existitu aurretik. Proxy lankide batek eskaera-mailako politika aplika dezake edo erantzuna cachean gorde dezake, bideratzaile izatearen itxurarik egin gabe.

Erantzuna «atebidea» bada, zerrendak huts egin du jada. Atebide batek fluxu ezagunak sailka ditzake helmugaren, markaren edo bezero-segmentuaren arabera eta lehen paketetik bide definitu batetik bidal ditzake; hori askotan nahikoa da onartutako eguneratzaile batentzat eta inoiz ez erantzun-tamaina ezezagun batentzat.

2. egiaztapena: zer esaten dizute metadatuek benetan?

Aplikazioaz jabetuta dagoen gidaritza irakurtzen dituen eremuak bezain ona da. HTTPren semantika barneko erantzun-luzerarako arauek uzten dituzte hasieran luzera eskuragarri ez dagoen kasuak, eta eduki-kodeketek transferitutako byte-kopurua errepresentazioaren tamainatik desberdin egiten dute, hala ere. Beraz, goiburu batek atalase bat gainditzean bidea aldatzen duen politikak modu koherentean jokatuko du, eta batez ere harrapatzeko xede ziren transferentzia handietan.

Aplikazio-metadatuak onar ditzaketena zeregin bati buruzko erabakia da: lan-fluxu hau sinkronizazio masiboa da, hura interaktiboa da, hura jatorri ezagun bateko software-eguneratzea da. Hori asmoaren hizkuntzan idatzitako politika da, eta nahikoa da egonkorra probatzeko. «Erantzun hau berrogei megabyte baino handiagoa izango da» ez da horrelako politika bat.

3. egiaztapena: fluxua jada existitzen da?

Bideratzeak fluxu batentzat alda daiteke konexioaren identitatea aldatu gabe, eta bereizketa hori garbi mantentzea merezi du. TCP konexioa bere muturren helbide eta ataken bidez identifikatzen da, eta paketeek beste bide bat har dezakete bideratze-taula haien azpian aldatzen bada. Modu ikusezinean aldatu ezin dena sare-helbideen itzulpenaren egoera da: trafikoa beste irteera batera mugitzeak normalean iturburu-tupla publikoa aldatzen du, eta urruneko muturrak egoera bat datorren beste pare bat ikusiko du.

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

Beraz, arau praktikoa da konexioaren erdian irteera batetik bestera mugitzea harreman berria dela, ez migrazioa. Diseinuak konexio berak jarraitzea eskatzen badu, erabakia lehen SYNaren aurretik hartu behar zen, eta geroago gehitutako pakete-arau batek ere ezin du garbi berreraiki.

4. egiaztapena: behar erreala latentzia da, ez irteera?

«Bidali trafiko masiboa beste toki batera» eskaera asko, egiatan, transferentzia handi batek lan interaktiboa motel sentiarazten duelako kexuak dira. Hori plangintza-arazo bat da, eta badu plangintza-erantzun bat: ilara zuzena edo onartutako banda-zabalera politika bat lehendik dagoen bidean, fluxu masibo batek txat-mezu bat gosez ez uzteko, bietako bat ere mugitu gabe.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Sintoma horrela jorratzeak irteera-erabakia segurtasun-politikak jarri zuen tokian uzten du, eta komando bakar batekin itzul daiteke. Trafiko-klase oso baten irteera aldatzea politika-aldaketa da, autentifikazio, erregistro eta sarbide-arauen ondorioekin, beraz ez litzateke latentezia-kexu baterako lehen tresna izan behar.

Baldintza benetan beste internet-irteera bat bada, esan hitz horiekin eta inplementatu onartutako muga batean: lan-fluxu onartu batetik datorren konexio berria, edo aukeratutako irteeraren bidez bere eskaera irekitzen duen aplikazio bat. Gero erregistratu zein zereginrek zein irteera erabiltzen duten, hurrengo pertsonak bideratze-taulatik ondorioztatu behar ez dezan.

Eutsi zerrenda aldaketaren erregistroan: erabaki-puntua, hura gidatzen duen eremua edo zeregina, fluxua jada badagoen, eta neurtutako sintoma latentzia ala irteera zen. Lau galdera, eta lauei erantzuten dien politika bat defendatu beharrean operatu dezakezun politika bat da.