Grandaj elŝutoj kontraŭ la VPN: elektu la vojon ĉe la peto

“Sendu la grandajn elŝutojn ĉirkaŭ la VPN kaj tenu la malgrandajn respondojn sur ĝi” sonas kiel enkursiga politiko, kaj ĝi ne estas. Enkursigilo decidas per informoj disponeblaj en tiu momento: adresoj, pordoj, protokolo, firewall-markoj, identigita fluo. La fina grando de respondo ne estas en tiu aro, ĉar ĝi ankoraŭ ne alvenis, kaj kiam la enkursigilo povus mezuri la bajtojn, ĝi jam portas ilin. Se vi volas direkti laŭ tasko, la decido devas moviĝi al punkto, kiu konas la taskon, kaj la kontrol-listo sube montras, ĉu via dezajno havas tian punkton.

Kial enkursigilo ne povas mezuri respondon

En la momento, kiam paketo bezonas vojon, la enkursigilo vidis plej multe la unuajn kelkajn paketojn de fluo. Ĝi povas diri, kiu parolas kun kiu, per kiu protokolo, kun kiu marko, kaj kiom da bajtoj jam pasis. Bajtoj ĝis nun priskribas la pasintecon. La grando de la respondo estas eco de respondo, kiu ankoraŭ ne estis generita, kaj por pecigitaj aŭ fluaj respondoj ĝi eble neniam estas anticipe konata.

Eĉ la propraj metadatumoj de la protokolo estas pli malfortaj ol ili ŝajnas. HTTP permesas respondojn, kies longo ne estas anoncita antaŭ la korpo, kaj unu uzanto-ago povas produkti multajn petojn, kies kombinita kosto tute ne similas al iu ajn kaplitera valoro. Trakti kapliteron kiel la grandecon de tasko estas modeliga eraro antaŭ ol ĝi estas enkursiga eraro.

Kontrolo 1: ĉu ekzistas decidpunkto, kiu povas elekti vojon?

Nomu la komponanton, kiu faros la elekton, kaj poste nomu, kion ĝi scias en la momento de la elekto. Ĝisdatigilo, kiu elŝutas el dokumentita aro de gastigantoj, konas sian celon antaŭ ol la transigo komenciĝas. Elŝuta servo, kiu konsultas metadatumojn kaj poste malfermas la peton, konas la taskon antaŭ ol la konekto ekzistas. Kunlabora proxy povas apliki politikon je peta nivelo aŭ kaŝmemorigi la respondon sen ŝajnigi esti enkursigilo.

Se la respondo estas “la pordego”, la kontrol-listo jam malsukcesis. Pordego povas klasifiki konatajn fluojn laŭ celo, marko aŭ klienta segmento kaj sendi ilin laŭ difinita vojo ekde la unua paketo, kio ofte sufiĉas por aprobita ĝisdatigilo kaj neniam sufiĉas por nekonata responda grando.

Kontrolo 2: kion la metadatumoj vere diras al vi?

Aplikaĵ-konscia direktado estas nur tiel bona, kiel la kampoj, kiujn ĝi legas. La reguloj pri responda longo en la semantiko de HTTP permesas kazojn, kie la longo ne disponeblas komence, kaj enhav-kodigoj igas la nombron de transigitaj bajtoj ĉiuokaze malsama ol la grando de la prezento. Do politiko, kiu ŝanĝas vojon kiam kaplitero transiras sojlon, kondutos malkonsekvence, kaj plejparte ĝuste ĉe la grandaj transigoj, kiujn ĝi celis kapti.

Kion aplikaĵaj metadatumoj povas subteni, estas decido pri tasko: ĉi tiu laborfluo estas amasa sinkronigo, ĉi tiu estas interaga, ĉi tiu estas programara ĝisdatigo el konata origino. Tio estas politiko skribita laŭ intenco, kaj ĝi estas sufiĉe stabila por esti testata. “Ĉi tiu respondo estos pli granda ol kvardek megabajtoj” ne estas tia politiko.

Kontrolo 3: ĉu la fluo jam ekzistas?

Enkursigado povas ŝanĝiĝi por fluo sen ŝanĝi la identecon de la konekto, kaj tiu distingo indas esti tenata rekta. TCP-konekto estas identigita per la finpunktaj adresoj kaj pordoj, kaj la paketoj povas preni alian vojon se la enkursiga tabelo ŝanĝiĝas sub ili. Kio ne povas ŝanĝiĝi nevideble, estas la stato de tradukado de retaj adresoj: movi trafikon al alia eliro kutime ŝanĝas la publikan fontan opon, kaj la fora flanko vidos alian kunulon sen kongrua stato.

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

Do la praktika regulo estas, ke moviĝo meze de konekto de unu eliro al alia estas nova rilato, ne migrado. Se la dezajno postulas, ke la sama konekto daŭru, la decido devis esti farita antaŭ la unua SYN, kaj neniu paketa regulo aldonita poste povas rekonstrui ĝin pure.

Kontrolo 4: ĉu la vera postulo estas latento, ne eliro?

Tre multaj petoj “sendu amasan trafikon aliloken” estas fakte plendoj, ke granda transigo igas interagan laboron sentiĝi malrapida. Tio estas planada problemo, kaj ĝi havas planadan respondon: justa atendovico aŭ subtenata bendolarga politiko sur la ekzistanta vojo malhelpas amasan fluon malsatigi babilmesaĝon sen movi iun el ili.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Trakti la simptomon tiel konservas la eliran decidon tie, kie la sekureca politiko metis ĝin, kaj ĝi estas reigebla per unu komando. Ŝanĝi la eliron por tuta klaso de trafiko estas politika ŝanĝo kun sekvoj por aŭtentikigo, protokolado kaj alirreguloj, do ĝi ne devus esti la unua ilo ĉe plendo pri latento.

Se la postulo vere estas alia interreta eliro, diru tion per tiuj vortoj kaj implementu ĝin ĉe subtenata limo: nova konekto el aprobita laborfluo, aŭ aplikaĵo, kiu malfermas sian propran peton tra elektita eliro. Poste registru, kiuj taskoj uzas kiun eliron, por ke la sekva persono ne devu dedukti tion el enkursiga tabelo.

Tenu la kontrol-liston en la ŝanĝa registro: la decidpunkton, la kampon aŭ taskon, kiu ĝin pelas, ĉu la fluo jam ekzistas, kaj ĉu la mezurita simptomo estis latento aŭ eliro. Kvar demandoj, kaj politiko, kiu respondas al ĉiuj kvar, estas tiu, kiun vi povas operacii anstataŭ defendi.