Oppdatering av VPN-gatewayen mislykkes: les trinnet før du åpner utgangen
En mislykket oppdatering navngir et trinn, ikke en manglende port. Koble meldingen til eieren, les proxybanen og bestem deretter vedlikeholdspolicyen med vilje.
Å nekte å installere sikkerhetsoppdateringer er bare én dårlig uke unna å bli noen andres problem, og en gateway som slipper inn klienter er det enkleste stedet å utvikle den vanen. Den vanlige årsaken er ikke en manglende rute, men en manglende beslutning: ingen har sagt hvordan verten selv skal nå et depot når videresending av klienter bevisst er smal. Den beslutningen må tas uttrykkelig, og den må være smalere enn å slå av utgangspolicyen en ettermiddag.
Fire trinn, fire ulike eiere
En oppdateringsfeil er et navngitt trinn, enten meldingen sier det eller ikke, og hvert trinn tilhører en ulik eier. Et navn som ikke lar seg slå opp, er et spørsmål for oppløseren. En tilkobling som får tidsavbrudd, er et spørsmål for transport, proxy eller den andre enden. En TLS-identitetsfeil er et tillitsspørsmål, og avviste arkivmetadata er et signaturspørsmål. Fire trinn, fire eiere, og en portregel svarer alltid bare på én 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 og navneoppslag er de to testene folk griper til først, og begge svarer på spørsmål ingen stilte. Et ekkosvar bruker en annen protokoll enn depotforbindelsen, og et vellykket oppslag stopper ved navneoppslag uten å teste hentingen. Begge kan bestå mens den faktiske transaksjonen feiler, og begge kan feile av grunner som ikke har noe med banen å gjøre.
Les banen pakkebehandleren faktisk tar
Undersøk de konfigurerte kilde-URI-ene og den faktiske proxyordningen i stedet for å anta en av dem. En regel skrevet for vanlig HTTP er ikke en reparasjon når depotet snakker HTTPS, og en organisasjon som krever proxy, har allerede valgt banen. Pakkebehandlere respekterer miljøvariabler og sin egen konfigurasjon, og vertsspesifikke innstillinger kan overstyre en global. Det en interaktiv nettleser gjør, trenger ikke være det pakkebehandleren gjør.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAPT-transportdokumentasjonen beskriver hvilke innstillinger som gjelder for hvilket URI-skjema, og hvordan vertsspesifikke valg skrives. Ta vare på kommandoutskriften sammen med saken, for den skiller et proxyproblem fra en manglende rute raskere enn noen mengde pingresultater. Skriv ned nøyaktig destinasjon, port og protokoll som pakkebehandleren forsøker, og la brannmur-endringen hvile på den registreringen i stedet for på en gjettet speiladresse som blir utdatert i løpet av måneder.
Velg en vedlikeholdspolicy, ikke et unntak
Tre policyer er forsvarlige: vedlikeholde gjennom tunnelen, vedlikeholde gjennom en administrert oppdateringsproxy eller vedlikeholde gjennom en smalt autorisert direkte rute. Hver av dem forutsetter en oppløserordning som passer til den. Det som ikke er forsvarlig, er et unntak som stille blir en ubegrenset reservevei hver gang tunnelen er nede.
Skriv ned den valgte policyen med en eier, for den neste operatøren finner regelen og ikke begrunnelsen bak den. Bruk tillatelsen gjennom den eksisterende brannmuren og nettverkseieren i stedet for å tømme regler eller legge til en annen policybehandler for én vert. Dekk adressefamiliene og tjenestesluttpunktene den virkelige kilden bruker, og gjennomgå listen når depotet flytter.
Verifiser uten å svekke tilliten
Vellykket transport er ikke tillatelse til å lempe på verifiseringen: arkivautentisering og TLS-serveridentitet er to ulike kontroller, og å slå av en av dem får en feil til å forsvinne samtidig som det endrer hva verten vil godta. En avlyttende proxy er en tillitsbeslutning fra nettverkseieren og ikke en grunn til å slå av kontrollen lokalt, og depotinnlogging hører ikke hjemme i delt diagnostikk, fordi en detaljert logg er det enkleste stedet å lekke dem.
Godta endringen med en kontrollert metadatahenting etterfulgt av én godkjent pakketransaksjon, og test deretter hva som skjer når tunnelen faller. En vedlikeholdsbane som stille utvides under en avbrudd, er verre enn en som feiler lukket, og resultatet bør være en oppdateringsbane med en navngitt eier og et avgrenset omfang.