Download grandi contro la VPN: scegliere il percorso alla richiesta

«Manda i download grandi fuori dalla VPN e tieni le risposte piccole dentro» suona come una politica di routing, e non lo è. Un router decide con le informazioni disponibili in quel momento: indirizzi, porte, protocollo, marcature del firewall, un flusso identificato. La dimensione finale di una risposta non è in quell'insieme, perché non è ancora arrivata, e quando il router potrebbe misurare i byte li sta già trasportando. Se volete dirigere per attività, la decisione deve spostarsi in un punto che conosca l'attività, e la lista di controllo qui sotto serve a scoprire se il vostro progetto ha quel punto.

Perché un router non può misurare una risposta

Nel momento in cui un pacchetto ha bisogno di una rotta, il router ha visto al massimo i primi pacchetti di un flusso. Può dire chi parla con chi, con quale protocollo, con quale marcatura e quanti byte sono passati finora. I byte finora descrivono il passato. La dimensione della risposta è una proprietà di una risposta non ancora generata, e per risposte frammentate o in streaming potrebbe non essere mai conoscibile in anticipo.

Persino i metadati del protocollo stesso sono più deboli di quanto sembrino. HTTP consente risposte la cui lunghezza non è annunciata prima del corpo, e una singola azione dell'utente può produrre molte richieste il cui costo complessivo non assomiglia a nessun valore di intestazione. Trattare un'intestazione come la dimensione di un'attività è un errore di modellazione prima che un errore di routing.

Controllo 1: esiste un punto di decisione che possa scegliere un percorso?

Nominate il componente che farà la scelta, poi nominate ciò che sa nel momento della scelta. Un aggiornatore che scarica da un insieme documentato di host conosce il proprio scopo prima che inizi il trasferimento. Un servizio di download che consulta i metadati e poi apre la richiesta conosce l'attività prima che la connessione esista. Un proxy collaborativo può applicare una politica a livello di richiesta o mettere in cache la risposta senza fingere di essere un router.

Se la risposta è «il gateway», la lista ha già fallito. Un gateway può classificare flussi noti per destinazione, marcatura o segmento client e inviarli su un percorso definito dal primo pacchetto, il che spesso basta per un aggiornatore approvato e non basta mai per una dimensione di risposta sconosciuta.

Controllo 2: cosa vi dicono davvero i metadati?

Il direzionamento consapevole dell'applicazione vale quanto i campi che legge. Le regole sulla lunghezza delle risposte in la semantica di HTTP ammettono casi in cui la lunghezza non è disponibile all'inizio, e le codifiche dei contenuti rendono comunque il numero di byte trasferiti diverso dalla dimensione della rappresentazione. Una politica che cambia percorso quando un'intestazione supera una soglia si comporterà quindi in modo incoerente, e soprattutto proprio sui trasferimenti grandi che doveva intercettare.

Ciò che i metadati applicativi possono sostenere è una decisione su un'attività: questo flusso di lavoro è una sincronizzazione massiva, questo è interattivo, questo è un aggiornamento software da un'origine nota. È una politica scritta in termini di intenzione, ed è abbastanza stabile da poter essere testata. «Questa risposta sarà più grande di quaranta megabyte» non è quel tipo di politica.

Controllo 3: il flusso esiste già?

Il routing può cambiare per un flusso senza cambiare l'identità della connessione, e questa distinzione va tenuta chiara. Una connessione TCP è identificata dagli indirizzi e dalle porte dei suoi estremi, e i pacchetti possono prendere un percorso diverso se la tabella di routing cambia sotto di loro. Ciò che non può cambiare in modo invisibile è lo stato di traduzione degli indirizzi di rete: spostare il traffico su un'altra uscita di solito cambia la tupla sorgente pubblica, e l'estremo remoto vedrà un peer diverso senza stato corrispondente.

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

La regola pratica è quindi che uno spostamento a metà connessione da un'uscita all'altra è una relazione nuova, non una migrazione. Se il progetto richiede che la stessa connessione continui, la decisione andava presa prima del primo SYN, e nessuna regola sui pacchetti aggiunta dopo può ricostruirla in modo pulito.

Controllo 4: il requisito reale è la latenza, non l'uscita?

Moltissime richieste di «mandare il traffico massivo altrove» sono in realtà lamentele sul fatto che un trasferimento grande rende lento il lavoro interattivo. È un problema di pianificazione, e ha una risposta di pianificazione: una coda equa o una politica di banda supportata sul percorso esistente impedisce a un flusso massivo di affamare un messaggio di chat senza spostare nessuno dei due.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Affrontare il sintomo in questo modo lascia la decisione sull'uscita dove l'ha messa la politica di sicurezza, ed è reversibile con un solo comando. Cambiare l'uscita per un'intera classe di traffico è un cambio di politica con conseguenze su autenticazione, registrazione e regole di accesso, quindi non dovrebbe essere il primo strumento a cui ricorrere per una lamentela sulla latenza.

Se il requisito è davvero un'uscita Internet diversa, ditelo con quelle parole e attuatelo a un confine supportato: una nuova connessione da un flusso di lavoro approvato, o un'applicazione che apre la propria richiesta attraverso un'uscita scelta. Poi registrate quali attività usano quale uscita, così la persona successiva non debba inferirlo da una tabella di routing.

Tenete la lista di controllo nel record della modifica: il punto di decisione, il campo o l'attività che lo guida, se il flusso esiste già e se il sintomo misurato era latenza o uscita. Quattro domande, e una politica che risponde a tutte e quattro è una che potete gestire invece di difendere.