Il tuo gateway VPN ha ancora bisogno di un modo per installare gli aggiornamenti

Il tunnel funziona per tutti quelli che stanno dietro, il gateway inoltra il loro traffico eppure la macchina stessa non riesce a installare un aggiornamento di sicurezza. Questa è la forma abituale del problema: l’autorizzazione all’inoltro è stata concessa ai client e le connessioni in uscita del gateway non sono mai state incluse nel piano. Il gestore dei pacchetti apre le proprie socket, dal gateway, verso un repository che probabilmente non avete mai nominato nella politica del firewall.

Bloccare un gateway è corretto. Bloccarlo in modo così completo da non ricevere più patch è una decisione diversa, e di solito accidentale.

L’uscita locale non è l’inoltro ai client

Le regole di inoltro governano i pacchetti che arrivano da altrove ed escono attraverso il gateway. Il traffico di aggiornamento del gateway stesso non le incontra mai; viene generato localmente e percorre il percorso di uscita. Questa distinzione spiega un guasto che sembra impossibile mentre l’accesso dei client funziona perfettamente.

Spiega anche una lacuna di politica che sopravvive ai test, perché un controllo rapido da un portatile dietro il tunnel dimostra che la catena di inoltro funziona e non dice nulla sulle connessioni proprie dell’host. Considerate il gateway come due soggetti: un router con una catena di inoltro e un host con una catena di uscita. Entrambi necessitano di una decisione, e di solito solo una delle due viene messa per iscritto.

Individuare la fase che ha fallito

Gli errori di aggiornamento indicano confini diversi, e cercare una regola di porta prima di aver letto quale è fallita fa perdere un pomeriggio. Un nome di repository che non si risolve è una questione di resolver, non una questione di trasporto.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

Un timeout dopo una risoluzione riuscita sposta la questione sul trasporto: quale indirizzo, quale porta e quale proxy configurato il gestore dei pacchetti ha effettivamente provato. Un errore di verifica TLS è una terza cosa del tutto diversa, e significa che la connessione ha funzionato abbastanza bene da negoziare. Una segnalazione di autenticazione dell’archivio è la quarta fase, e riguarda metadati firmati anziché la raggiungibilità. Quattro fasi, quattro riparazioni diverse, e un ping descrive sempre e solo un protocollo che nessun gestore di pacchetti usa.

Leggere l’elenco delle fonti prima di aggiungere una regola

Elencate gli URI reali delle fonti e la configurazione proxy effettiva invece di quelli che ricordate. Una regola scritta per HTTP semplice è inutile quando la fonte è HTTPS, e un proxy che la shell conosce può essere invisibile a un servizio avviato al boot con un ambiente diverso.

La documentazione del trasporto HTTP di APT copre le impostazioni proxy dell’ambiente e specifiche di APT, comprese le scelte per host, e il suo trasporto HTTPS ha impostazioni di verifica proprie. Il percorso di un browser e quello del gestore dei pacchetti sono percorsi separati, anche sulla stessa macchina.

Notate a quali famiglie risolvono le fonti. Una regola che consente solo IPv4 continuerà a fallire su un host le cui fonti preferiscono un record AAAA, e l’errore sembra intermittente perché dipende da quale risposta arriva per prima.

Scegliere un solo percorso di manutenzione e mantenerlo

Esistono tre opzioni difendibili: il traffico di manutenzione attraverso il tunnel, attraverso un proxy di aggiornamento gestito o attraverso un’eccezione diretta ristretta. Sceglietene una deliberatamente e fate in modo che il resolver sia d’accordo, perché una divisione in cui i nomi si risolvono in un modo e le connessioni vanno in un altro produce guasti che nessuno sa spiegare.

Qualunque cosa scegliate, non deve diventare un ripiego senza restrizioni. Se il traffico in uscita diretto è vietato quando il tunnel è inattivo, un’eccezione di manutenzione che consente tranquillamente tutto è un cambiamento di politica travestito da correzione. Tenete l’endpoint del tunnel e le sue esigenze di bootstrap in una categoria separata dall’accesso ai repository, perché puntano a destinazioni diverse e falliscono in modi diversi, quindi un’esenzione non può coprire l’altra.

Verificare senza indebolire i controlli

Applicate l’ambito tramite il firewall che già possiede la politica, invece di aggiungere un secondo gestore perché una guida lo usava. Poi eseguite un aggiornamento dei metadati e una transazione reale di pacchetti con la politica mantenuta, e leggete l’output invece del solo codice di uscita.

Il successo del trasporto non è il permesso di allentare la verifica. L’autenticazione dell’archivio e l’identità del server TLS sono garanzie separate, e disattivare l’una o l’altra per far tacere un errore cambia ciò di cui vi fidate, non ciò che potete raggiungere.

Concludete testando deliberatamente il caso di tunnel inattivo. Sapere come si comporta il gateway senza il suo tunnel fa parte del progetto, scoprirlo durante un’interruzione no. Disattivate il tunnel, eseguite l’aggiornamento dei metadati e confermate che l’host fallisce nel modo previsto invece di ricadere silenziosamente su un percorso aperto. Tenete le credenziali di repository e proxy fuori dalle diagnostiche condivise e lasciate una nota che indichi chi è responsabile del percorso di aggiornamento.