Il TCP 443 aiuta davvero? Solo se il server ascolta lì

Il TCP 443 è un ripiego con un prerequisito, non un travestimento che fa passare un tunnel attraverso qualsiasi filtro. Aiuta quando l’operatore pubblica già un ascoltatore TCP su quella porta e il percorso tollera una connessione che resta aperta per ore. Fallisce, di solito come timeout, quando manca una delle due cose, e il timeout raramente dice quale. Decidere se cambiare richiede tre domande, e solo una riguarda il numero di porta.

Un numero di porta non è una promessa di trasporto

Una porta nomina un estremo; il TCP la trasforma in un flusso ordinato di byte; OpenVPN decide cosa viaggia dentro quel flusso. Un server web sullo stesso numero usa una disposizione applicativa del tutto diversa, quindi condividere la porta 443 rende i due simili per un filtro e nulla più. Il numero è un indizio che un filtro legge, non una proprietà che cambia ciò che contengono i pacchetti. Trattarli come la stessa cosa perché condividono una porta è l’errore dietro gran parte della confusione.

I dispositivi intermedi raramente prendono una decisione semplice di consentire o negare su una porta. Molti ispezionano i primi byte, alcuni fissano una destinazione e altri azzerano connessioni che restano aperte troppo a lungo. Per questo lo stesso profilo può funzionare da una rete e scadere da un’altra, e per questo vale la pena provare il ripiego come opzione supportata invece di fidarsi come di una promessa. Quando un filtro esamina il traffico, il numero di porta è solo la prima cosa che guarda.

Confermate l’ascoltatore prima di toccare il profilo

Il server deve essere configurato per TCP su quella porta, e il profilo client deve chiedere lo stesso trasporto. Riscrivere un profilo UDP perché chieda TCP non crea l’ascoltatore, e il timeout che ne deriva non si distingue da un firewall che scarta la porta. Scaricate il profilo TCP dell’operatore quando esiste, perché alcuni servizi pubblicano un estremo e impostazioni di identità separati per ogni trasporto. Modificare a mano va bene per un test controllato ed è un pessimo modo di indovinare la configurazione voluta dal fornitore.

I due lati di quella corrispondenza compaiono nella configurazione, e le opzioni di collegamento del progetto OpenVPN documentano entrambe le forme. La coppia minima ha questo aspetto:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Tre condizioni decidono se il ripiego vale la spesa

La prima condizione è che l’operatore offra il trasporto; senza di esso nulla d’altro conta. La seconda è che il percorso mantenga viva una sessione di lunga durata, dato che alcune reti azzerano le connessioni che restano aperte invece di bloccare la porta del tutto. La terza è se il ripiego sia un’eccezione deliberata o una toppa che nasconde un guasto che non avete corretto.

Ogni condizione ha un controllo economico. Un fallimento su una qualsiasi di esse si vede allo stesso modo dal client:

Prima di confrontare i trasporti, completate qualsiasi accesso a un portale captive. Una rete che non ha ammesso il vostro dispositivo blocca entrambi i trasporti, e allora il confronto misura il portale e non il tunnel. Accedete, confermate che la navigazione normale funziona, e solo dopo avviate il test.

Il costo che accettate: TCP dentro TCP

Il TCP ritrasmette i segmenti persi e ne preserva l’ordine. Quando un’applicazione che usa anch’essa TCP gira dentro un tunnel TCP, due livelli di recupero reagiscono alla stessa perdita, ed è questa interazione a rendere il tunnel lento su un percorso con perdite. Il sintomo è ritardo e jitter più che un guasto netto, il che rende facile dare la colpa all’estremo remoto. Misurate dal client con entrambi i trasporti prima di concludere.

L’UDP evita questo annidamento, ed è il motivo principale per cui gli operatori lo preferiscono e offrono TCP solo come alternativa. Una connessione TCP stabile resta più utile di una UDP irraggiungibile, quindi il confronto è tra due costi reali e non tra un’opzione buona e una cattiva. Tenete fermi il dispositivo e la rete di accesso mentre confrontate, altrimenti il risultato descrive la variabile sbagliata.

Alcune funzioni del client sono documentate solo per un trasporto, quindi un profilo di ripiego può perdere in silenzio un comportamento su cui contavate. Leggete il requisito di trasporto dell’opzione prima di trattare il profilo TCP come un semplice scambio.

Guasti che un altro trasporto non tocca

Un certificato scaduto ha ancora bisogno di un controllo dell’orologio o di un rinnovo, e un account rifiutato ha ancora bisogno delle credenziali giuste. Mantenete i controlli di identità del server forniti dall’operatore, perché un numero di porta familiare non autentica nessuno. Una porta che risponde dice solo che qualcosa è in ascolto.

Se il tunnel sale e le destinazioni continuano a fallire, il problema restante è l’instradamento o la risoluzione dei nomi dopo la connessione, non il trasporto. Seguite quel percorso invece di girare tra le porte, perché è così che svanisce un pomeriggio. Il profilo vi dice quale trasporto provare; non vi dice mai perché il percorso UDP ha fallito.