Opdatering af VPN-gatewayen fejler: læs trinnet, før du åbner udgangen
En mislykket opdatering nævner et trin, ikke en manglende port. Kobl meddelelsen til dens ejer, læs proxy-stien, og beslut derefter vedligeholdelsespolitikken med overlæg.
At nægte at installere sikkerhedsopdateringer er kun en dårlig uge fra at blive en andens problem, og en gateway, der lukker klienter ind, er det nemmeste sted at udvikle den vane. Den sædvanlige årsag er ikke en manglende rute, men en manglende beslutning: ingen har sagt, hvordan værten selv skal nå et repository, når videresendelse af klienter bevidst er snæver. Den beslutning skal træffes udtrykkeligt, og den skal være snævrere end at slukke for udgangspolitikken en eftermiddag.
Fire trin, fire forskellige ejere
En opdateringsfejl er et navngivet trin, uanset om meddelelsen siger det, og hvert trin tilhører en forskellig ejer. Et navn, der ikke kan slås op, er et spørgsmål for navneopløsningen. En forbindelse, der timer ud, er et spørgsmål for transport, proxy eller den fjerne ende. En TLS-identitetsfejl er et tillidsspørgsmål, og afviste arkivmetadata er et signeringsspørgsmål. Fire trin, fire ejere, og en portregel besvarer altid kun én af 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 og navneopløsning er de to tests, folk først griber efter, og begge besvarer spørgsmål, ingen stillede. Et ekkosvar bruger en anden protokol end repository-forbindelsen, og et vellykket opslag stopper ved navneopløsning uden at teste hentningen. Begge kan bestå, mens den egentlige transaktion fejler, og begge kan fejle af grunde, der intet har med stien at gøre.
Læs den sti, som pakkehåndteringen faktisk tager
Undersøg de konfigurerede kilde-URI'er og den effektive proxy-ordning i stedet for at antage en af dem. En regel skrevet til almindelig HTTP er ikke en reparation, når repository'et taler HTTPS, og en organisation, der kræver en proxy, har allerede valgt stien. Pakkehåndteringer respekterer miljøvariabler og deres egen konfiguration, og værtspecifikke indstillinger kan tilsidesætte en global. Hvad en interaktiv browser gør, behøver ikke være det, pakkehåndteringen gør.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAPT-transportdokumentationen beskriver, hvilke indstillinger der gælder for hvilket URI-skema, og hvordan værtspecifikke valg skrives. Gem kommandoernes output sammen med sagen, for det adskiller et proxy-problem fra en manglende rute hurtigere end nogen mængde ping-resultater. Skriv den præcise destination, port og protokol ned, som pakkehåndteringen forsøger, og lad firewall-ændringen hvile på den registrering frem for på en gættet spejladresse, der bliver forældet inden for måneder.
Vælg en vedligeholdelsespolitik, ikke en undtagelse
Tre politikker er forsvarlige: vedligehold gennem tunnelen, vedligehold gennem en administreret opdateringsproxy eller vedligehold gennem en snævert autoriseret direkte rute. Hver af dem forudsætter en navneopløsningsordning, der passer til den. Det, der ikke er forsvarligt, er en undtagelse, der stille bliver et ubegrænset reservehjul, hver gang tunnelen er nede.
Skriv den valgte politik ned med en ejer, for den næste operatør finder reglen og ikke begrundelsen bag den. Anvend tilladelsen gennem den eksisterende firewall og netværksejeren i stedet for at skylle regler eller tilføje en anden politikmanager for én vært. Dæk de adressefamilier og tjenestepunkter, som den rigtige kilde bruger, og gennemgå listen, når repository'et flytter.
Verificér uden at svække tilliden
En vellykket transport er ikke tilladelse til at lempe verifikationen: arkivautentificering og TLS-serveridentitet er to forskellige kontroller, og deaktivering af en af dem får en fejl til at forsvinde, mens det ændrer, hvad værten vil acceptere. En opfangende proxy er en tillidsbeslutning for netværksejeren frem for en grund til at slå kontrollen fra lokalt, og repository-legitimationsoplysninger hører ikke hjemme i delte diagnostikker, fordi en udførlig log er det nemmeste sted at lække dem.
Accepter ændringen med en kontrolleret metadatahentning efterfulgt af én godkendt pakketransaktion, og test derefter, hvad der sker, når tunnelen falder. En vedligeholdelsessti, der stille udvider sig under en afbrydelse, er værre end en, der fejler lukket, og resultatet bør være en opdateringssti med en navngivet ejer og et afgrænset omfang.