Un portatile con VPN ha bisogno dell’inoltro IP per andare più veloce?

Trasformare il portatile in un router è un modo popolare di risolvere il problema sbagliato. L’inoltro esiste perché una macchina possa passare pacchetti la cui destinazione non è se stessa, e non ha opinioni su quanto rapidamente un browser sulla stessa macchina carichi una pagina. I due percorsi sembrano uguali solo perché entrambi inviano traffico attraverso un unico tunnel. Sepàrali una volta e gran parte dei consigli su abilitare l’inoltro o aprire il firewall si rivela descrivere una topologia che non avete.

Due percorsi di pacchetti che dalla scrivania sembrano identici

Il browser sul portatile crea la propria richiesta. L’host sceglie la rotta del tunnel, il processo client incapsula il pacchetto e lo invia al peer, e la risposta torna all’applicazione. Nulla in quella sequenza attraversa una decisione di inoltro, perché questa macchina è sia la fonte sia la destinazione della conversazione.

Ora mettete un altro dispositivo su un segmento Ethernet configurato di proposito e fate del portatile il suo gateway predefinito. Quel dispositivo origina la richiesta, il portatile riceve un pacchetto indirizzato altrove e il kernel deve decidere se inoltrarlo. È il ruolo di inoltro, e arriva con prerequisiti che il ruolo client non ha mai avuto: un percorso di transito consentito, rotte su entrambi i lati e un percorso di ritorno che funziona ancora se la traduzione fa parte del progetto.

Cosa cambia davvero ip_forward

La documentazione del kernel su IPv4 sysctl descrive ip_forward come l’interruttore che permette a un host di inoltrare pacchetti tra interfacce. Non è una via rapida per il traffico generato dall’host stesso, e nessuna lettura di quel parametro rende più veloce un browser locale. Semmai, l’inoltro aggiunge stato e policy a una macchina che prima faceva meno lavoro.

La stessa documentazione avverte che cambiare il valore ripristina altri parametri IPv4 ai loro valori predefiniti di host o router. Ciò rende l’interruttore un evento di configurazione anziché una prova: impostazioni messe a punto possono tornare indietro sotto i vostri piedi, e la modifica può essere responsabile di una regressione che nessuno penserebbe di attribuirle. Significa anche che l’interruttore va impostato una volta, deliberatamente, da chi possiede il ruolo di gateway. Girarlo durante un’indagine su una lentezza è l’unico caso in cui l’effetto collaterale è garantito confuso con il sintomo.

Tre domande del firewall che non sono la stessa domanda

Consentire un listener VPN, consentire i servizi che il portatile esegue e consentire al traffico di attraversare il portatile sono tre permessi separati. Il primo lascia che un peer raggiunga un demone, il secondo espone qualcosa di locale e il terzo trasforma la macchina in transito per qualcun altro. Ognuno ha una portata diversa, e l’ultimo è molto più ampio delle risposte che serve a un’applicazione in uscita ordinaria.

Quando un flusso specifico è bloccato, nominate la sua origine, destinazione, direzione e il proprietario della policy prima di modificare una regola. Una regola stretta per quel flusso è una correzione; accettare tutto sull’interfaccia del tunnel è un cambio di policy che include la correzione per caso. Un browser che funziona dopo dimostra che il flusso funziona, non che la regola ampia fosse necessaria.

Misurate solo quando il percorso è corretto

Misurate con la stessa destinazione, lo stesso carico e condizioni confrontabili, e cambiate una variabile alla volta. Un test che raggruppa una modifica di inoltro, un ampliamento del firewall e un’impostazione di cifratura copiata produce un numero e nessuna spiegazione, perché nulla in esso dice quale delle tre cose ha spostato il risultato.

Tenete i guasti di rotta e di resolver completamente fuori dalla conversazione sulle prestazioni. Un nome che si risolve lentamente non è un problema di throughput, e un trasferimento che si blocca a una dimensione fissa è di solito una questione di MTU e non un limite di velocità. Annotate quale di queste tre cose avete davvero osservato prima di confrontare qualsiasi numero. Altrimenti il lettore successivo eredita una misura che misura la cosa sbagliata e una modifica che nessuno può giustificare.

Descrivete la topologia che avete, non l’etichetta sul client

Un portatile che condivide la sua connessione, ospita una rete di container instradata o trasporta traffico per una macchina virtuale è un gateway, qualunque nome si dia il software. La parola client descrive come è configurato il tunnel, non se i pacchetti vengono passati a qualcun altro.

Rendete esplicito il ruolo nel manuale operativo: cosa origina il traffico, cosa deve attraversare la macchina e quale delle due cose riguarda l’attività corrente. Abilitate il ruolo di gateway quando appartiene al piano supportato, non come una regolazione di velocità inspiegata applicata a una topologia che non ne ha mai avuto bisogno.