La vostra porta d’enllaç VPN encara necessita una manera d’instal·lar actualitzacions
Una porta d’enllaç bloquejada ha d’arribar igualment als seus repositoris. Esbrineu quina etapa ha fallat i després permeteu exactament aquest camí en lloc d’obrir el trànsit sortint.
El túnel funciona per a tots els qui hi ha darrere, la porta d’enllaç reenvia el seu trànsit i, això no obstant, la màquina mateixa no pot instal·lar una actualització de seguretat. Aquesta és la forma habitual del problema: el permís de reenviament es va concedir als clients, i les connexions sortints pròpies de la porta d’enllaç no es van incloure mai al pla. El gestor de paquets obre els seus propis sockets, des de la porta d’enllaç, cap a un repositori que probablement no heu anomenat enlloc de la política del tallafoc.
Bloquejar una porta d’enllaç és correcte. Bloquejar-la tan a fons que deixi de rebre pedaços és una altra decisió, i normalment accidental.
La sortida local no és el reenviament de clients
Les regles de reenviament regeixen els paquets que arriben d’un altre lloc i surten per la porta d’enllaç. El trànsit d’actualització propi de la porta d’enllaç no hi coincideix mai; es genera localment i recorre el camí de sortida. Aquesta distinció explica una fallada que sembla impossible mentre l’accés dels clients funciona perfectament.
També explica una llacuna de política que sobreviu a les proves, perquè una comprovació ràpida des d’un portàtil darrere del túnel demostra que la cadena de reenviament funciona i no diu res de les connexions pròpies de l’host. Tracteu la porta d’enllaç com dos subjectes: un encaminador amb una cadena de reenviament i un host amb una cadena de sortida. Tots dos necessiten una opinió, i normalment només se n’escriu una.
Anomeneu l’etapa que ha fallat
Els errors d’actualització anomenen límits diferents, i recórrer a una regla de port abans de llegir quina ha fallat costa una tarda. Un nom de repositori que no es resol és una qüestió de resolutor, no una qüestió de transport.
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 temps d’espera després d’una resolució correcta desplaça la pregunta cap al transport: quina adreça, quin port i quin proxy configurat va provar realment el gestor de paquets. Una fallada de verificació TLS és una tercera cosa, completament diferent, i significa que la connexió va funcionar prou bé per negociar. Una queixa d’autenticació de l’arxiu és la quarta etapa, i fa referència a metadades signades i no a l’abastabilitat. Quatre etapes, quatre reparacions diferents, i un ping sempre descriu només un protocol que cap gestor de paquets utilitza.
Llegiu la llista de fonts abans d’afegir una regla
Enumerou els URI reals de les fonts i la configuració efectiva de proxy, no els que recordeu. Una regla escrita per a HTTP simple és inútil quan la font és HTTPS, i un proxy que el shell coneix pot ser invisible per a un servei iniciat a l’arrencada amb un altre entorn.
La documentació del transport HTTP d’APT cobreix els paràmetres de proxy de l’entorn i els específics d’APT, incloent-hi les tries per host, i el seu transport HTTPS té paràmetres de verificació propis. El camí d’un navegador i el camí del gestor de paquets són camins separats, fins i tot a la mateixa màquina.
Fixeu-vos en quines famílies resolen les fonts. Una regla que només permet IPv4 continuarà fallant en un host les fonts del qual prefereixen un registre AAAA, i l’error sembla intermitent perquè depèn de quina resposta arriba primer.
Trieu un sol camí de manteniment i manteniu-lo
Hi ha tres opcions defensables: trànsit de manteniment pel túnel, per un proxy d’actualitzacions gestionat o per una excepció directa estreta. Trieu-ne una deliberadament i feu que el resolutor hi estigui d’acord, perquè una divisió en què els noms es resolen d’una manera i les connexions van d’una altra produeix fallades que ningú no pot explicar.
Trieu el que trieu, no ha de convertir-se en un recurs de reserva sense restriccions. Si el trànsit sortint directe està prohibit quan el túnel està caigut, una excepció de manteniment que permet en silenci tot és un canvi de política disfressat de correcció. Manteniu el punt final propi del túnel i les necessitats d’arrencada en una categoria separada de l’accés als repositoris, perquè apunten a destinacions diferents i fallen de maneres diferents, de manera que una exempció no pot cobrir l’altra.
Verifiqueu sense afeblir les comprovacions
Apliqueu l’abast a través del tallafoc que ja posseeix la política, en lloc d’afegir un segon gestor perquè una guia el va fer servir. Després executeu una actualització de metadades i una transacció real de paquets sota la política mantinguda, i llegiu la sortida en lloc del codi de sortida sol.
Un transport correcte no és permís per relaxar la verificació. L’autenticació de l’arxiu i la identitat del servidor TLS són garanties separades, i desactivar qualsevol de les dues per silenciar un error canvia allò en què confieu, no allò que podeu assolir.
Acabeu provant deliberadament el cas sense túnel. Saber com es comporta la porta d’enllaç sense el seu túnel forma part del disseny, descobrir-ho durant una interrupció no. Baixeu el túnel, executeu l’actualització de metadades i confirmeu que l’host falla de la manera prevista en lloc de recular en silenci cap a un camí obert. Manteniu les credencials dels repositoris i del proxy fora dels diagnòstics compartits i deixeu una nota que indiqui qui és responsable del camí d’actualització.