Uppdatering av VPN-gatewayen misslyckas: läs steget innan du öppnar utgången
En misslyckad uppdatering namnger ett steg, inte en saknad port. Koppla meddelandet till dess ägare, läs proxyvägen och bestäm sedan underhållspolicyn med avsikt.
Att vägra installera säkerhetsuppdateringar är bara en dålig vecka från att bli någon annans problem, och en gateway som släpper in klienter är den enklaste platsen att utveckla den vanan. Den vanliga orsaken är inte en saknad rutt utan ett saknat beslut: ingen har sagt hur värden själv ska nå ett arkiv när vidarebefordran av klienter medvetet är snäv. Det beslutet måste fattas uttryckligen, och det måste vara snävare än att stänga av utgångspolicyn en eftermiddag.
Fyra steg, fyra olika ägare
Ett uppdateringsfel är ett namngivet steg, oavsett om meddelandet säger det eller inte, och varje steg tillhör en annan ägare. Ett namn som inte kan slås upp är en fråga för resolvern. En anslutning som får tidsutbrott är en fråga för transport, proxy eller den bortre änden. Ett TLS-identitetsfel är en förtroendefråga, och avvisade arkivmetadata är en signaturfråga. Fyra steg, fyra ägare, och en portregel svarar alltid bara på en av dem.
| 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 |
Ping och namnuppslagning är de två tester som folk först tar till, och båda svarar på frågor som ingen ställde. Ett ekosvar använder ett annat protokoll än arkivanslutningen, och en lyckad uppslagning stannar vid namnuppslagning utan att testa hämtningen. Båda kan lyckas medan den verkliga transaktionen misslyckas, och båda kan misslyckas av skäl som inte har med vägen att göra.
Läs den väg som hanteraren faktiskt tar
Granska de konfigurerade käll-URI:erna och det faktiska proxyupplägget i stället för att anta något av dem. En regel skriven för vanlig HTTP är ingen reparation när arkivet talar HTTPS, och en organisation som kräver proxy har redan valt vägen. Pakethanterare respekterar miljövariabler och sin egen konfiguration, och värdspecifika inställningar kan åsidosätta en global. Vad en interaktiv webbläsare gör behöver inte vara vad hanteraren gör.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAPT-transportdokumentationen beskriver vilka inställningar som gäller för vilket URI-schema och hur värdspecifika val skrivs. Spara kommandoutskriften med ärendet, eftersom den skiljer ett proxyproblem från en saknad rutt snabbare än något antal pingresultat. Skriv ner exakt destination, port och protokoll som hanteraren försöker, och låt brandväggsändringen vila på den anteckningen i stället för på en gissad spegeladress som blir inaktuell inom månader.
Välj en underhållspolicy, inte ett undantag
Tre policyn är försvarbara: underhåll via tunneln, underhåll via en hanterad uppdateringsproxy eller underhåll via en snävt auktoriserad direktväg. Var och en förutsätter ett resolverupplägg som passar den. Det som inte är försvarbart är ett undantag som tyst blir en obegränsad reservväg varje gång tunneln ligger nere.
Skriv ner den valda policyn med en ägare, eftersom nästa operatör hittar regeln och inte resonemanget bakom den. Tillämpa tillståndet genom den befintliga brandväggen och nätverksägaren i stället för att spola regler eller lägga till en andra policyhanterare för en enda värd. Täck de adressfamiljer och tjänsteslutpunkter som den verkliga källan använder, och se över listan när arkivet flyttar.
Verifiera utan att försvaga förtroendet
En lyckad transport är inte tillstånd att lätta på verifieringen: arkivautentisering och TLS-serveridentitet är två olika kontroller, och att stänga av någon av dem får ett fel att försvinna samtidigt som det ändrar vad värden kommer att acceptera. En avlyssnande proxy är ett förtroendebeslut av nätverksägaren och inte ett skäl att stänga av kontrollen lokalt, och arkivets inloggningsuppgifter hör inte hemma i delad diagnostik, eftersom en utförlig logg är den enklaste platsen att läcka dem.
Acceptera ändringen med en kontrollerad metadatainsamling följd av en godkänd pakettransaktion, och testa sedan vad som händer när tunneln faller. En underhållsväg som tyst vidgas under ett avbrott är sämre än en som misslyckas stängd, och resultatet bör vara en uppdateringsväg med en namngiven ägare och en avgränsad omfattning.