Fallou a actualización da pasarela VPN: le a etapa antes de abrir a saída
Unha actualización fallida nomea unha etapa, non un porto que falta. Vincula a mensaxe co seu dono, le o camiño do proxy e despois decide a política de mantemento a propósito.
Negarse a instalar actualizacións de seguridade está a unha mala semana de converterse no problema doutra persoa, e unha pasarela que admite clientes é o lugar máis doado para desenvolver ese hábito. A causa habitual non é unha ruta que falta senón unha decisión que falta: ninguén dixo como debe chegar o propio host a un repositorio cando o reenvío de clientes é deliberadamente estreito. Esa decisión ten que tomarse de forma explícita, e ten que ser máis estreita que desactivar a política de saída durante unha tarde.
Catro etapas, catro donos distintos
Un fallo de actualización é unha etapa con nome, dígao a mensaxe ou non, e cada etapa pertence a un dono distinto. Un nome que non se resolve é unha cuestión do resolutor. Unha conexión que esgota o tempo é unha cuestión do transporte, do proxy ou do extremo remoto. Un erro de identidade TLS é unha cuestión de confianza, e os metadatos de arquivo rexeitados son unha cuestión de sinatura. Catro etapas, catro donos, e unha regra de porto só responde a unha delas.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
O ping e a resolución de nomes son as dúas probas ás que a xente recorre primeiro, e ambas responden preguntas que ninguén fixo. Unha resposta de eco exerce un protocolo distinto do da conexión ao repositorio, e unha consulta correcta detense na resolución de nomes sen probar a recuperación. Calquera das dúas pode pasar mentres a transacción real falla, e calquera pode fallar por motivos que non teñen relación co camiño.
Le o camiño que o xestor toma realmente
Inspecciona os URI de orixe configurados e a disposición efectiva do proxy en lugar de supoñer ningún dos dous. Unha regra escrita para HTTP simple non é unha reparación cando o repositorio fala HTTPS, e unha organización que esixe un proxy xa escolleu o camiño. Os xestores de paquetes respectan as variables de contorno e a súa propia configuración, e os axustes específicos do host poden anular un global. O que fai un navegador interactivo non ten por que ser o que fai o xestor.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyA documentación do transporte de APT describe que axustes se aplican a cada esquema de URI e como se escriben as escollas específicas do host. Garda a saída dos comandos co tícket, porque separa un problema de proxy dunha ruta que falta máis rápido que calquera número de resultados de ping. Anota o destino, o porto e o protocolo exactos que intenta o xestor, e deixa que o cambio de cortalumes se apoie nese rexistro en lugar dun enderezo de espello suposto que queda obsoleto en cuestión de meses.
Escolle unha política de mantemento, non unha excepción
Tres políticas son defendibles: manter a través do túnel, manter a través dun proxy de actualización xestionado ou manter a través dunha ruta directa estreitamente autorizada. Cada unha implica unha disposición do resolutor que encaixa con ela. O que non é defendible é unha excepción que se converte en silencio nun recurso ilimitado sempre que o túnel está caído.
Anota a política escollida cun dono, porque o seguinte operador atopará a regra e non o razoamento que hai detrás. Aplica o permiso a través da cortalumes existente e do dono da rede en lugar de baleirar regras ou engadir un segundo xestor de políticas para un só host. Cobre as familias de enderezos e os puntos de servizo que usa a fonte real, e revisa a lista cando o repositorio se mova.
Verifica sen debilitar a confianza
O éxito do transporte non é permiso para relaxar a verificación: a autenticación do arquivo e a identidade do servidor TLS son dúas comprobacións distintas, e desactivar calquera delas fai desaparecer un erro mentres cambia o que o host aceptará. Un proxy que intercepta é unha decisión de confianza do dono da rede, non un motivo para desactivar a comprobación localmente, e as credenciais do repositorio non deben estar en diagnósticos compartidos, porque un rexistro detallado é o lugar máis doado para filtralas.
Acepta o cambio cunha recuperación controlada de metadatos seguida dunha transacción de paquetes aprobada, e despois proba que ocorre cando o túnel cae. Unha ruta de mantemento que se ensancha en silencio durante unha interrupción é peor ca unha que falla pechada, e o resultado debería ser unha ruta de actualización cun dono nomeado e un alcance delimitado.