VPN-gatewayen din trenger fortsatt en måte å installere oppdateringer

Tunnelen fungerer for alle bak den, gatewayen videresender trafikken deres, og likevel kan maskinen selv ikke installere en sikkerhetsoppdatering. Dette er den vanlige formen problemet har: videresendingstillatelsen ble gitt til klientene, og gatewayens egne utgående forbindelser ble aldri inkludert i planen. Pakkebehandleren åpner sine egne sockets, fra gatewayen, til et depot du sannsynligvis ikke har navngitt noe sted i brannmurpolicyen.

Det er riktig å låse ned en gateway. Å låse den så grundig ned at den slutter å motta oppdateringer, er en annen beslutning, og vanligvis en tilfeldig en.

Lokal utgang er ikke klientvideresending

Videresendingsregler gjelder pakker som kommer fra et annet sted og forlater gjennom gatewayen. Gatewayens egen oppdateringstrafikk treffer dem aldri; den genereres lokalt og går gjennom utgangsstien. Den forskjellen forklarer en feil som virker umulig mens klienttilgang fungerer perfekt.

Den forklarer også et hull i policyen som overlever testing, fordi en rask sjekk fra en bærbar PC bak tunnelen beviser at videresendingskjeden fungerer og ikke sier noe om vertens egne forbindelser. Behandle gatewayen som to subjekter: en ruter med en videresendingskjede og en vert med en utgangskjede. Begge trenger en mening, og bare én av dem blir vanligvis skrevet ned.

Navngi trinnet som feilet

Oppdateringsfeil navngir forskjellige grenser, og å gripe etter en portregel før du leser hvilken som feilet koster en ettermiddag. Et depotnavn som ikke lar seg slå opp, er et resolver-spørsmål, ikke et transportspørsmål.

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

En tidsavbrudd etter et vellykket oppslag flytter spørsmålet til transport: hvilken adresse, hvilken port og hvilken konfigurert proxy pakkebehandleren faktisk forsøkte. En TLS-verifiseringsfeil er noe helt annet, og det betyr at forbindelsen fungerte godt nok til å forhandle. En klage på arkivautentisering er det fjerde trinnet, og den handler om signerte metadata snarere enn nåbarhet. Fire trinn, fire forskjellige reparasjoner, og en ping beskriver alltid bare én protokoll som ingen pakkebehandler bruker.

Les kildelisten før du legger til en regel

List opp de faktiske kilde-URI-ene og den effektive proxykonfigurasjonen i stedet for dem du husker. En regel skrevet for vanlig HTTP er ubrukelig når kilden er HTTPS, og en proxy som skallet kjenner til kan være usynlig for en tjeneste som startes ved oppstart med et annet miljø.

APT sin dokumentasjon av HTTP-transport dekker miljø- og APT-spesifikke proxyinnstillinger, inkludert valg per vert, og HTTPS-transporten har egne verifiseringsinnstillinger. Stien en nettleser tar og stien pakkebehandleren tar er atskilte stier, selv på samme maskin.

Legg merke til hvilke familier kildene slår opp til. En regel som bare tillater IPv4 vil fortsette å feile på en vert der kildene foretrekker en AAAA-post, og feilen virker periodisk fordi den avhenger av hvilket svar som kommer først.

Velg én vedlikeholdsvei og hold deg til den

Tre forsvarlige alternativer finnes: vedlikeholdstrafikk gjennom tunnelen, gjennom en administrert oppdateringsproxy eller gjennom et smalt direkte unntak. Velg ett bevisst og sørg for at resolveren er enig, fordi en deling der navn slås opp den ene veien og forbindelser går den andre gir feil ingen kan forklare.

Uansett hva du velger, må det ikke bli en ubegrenset reserveløsning. Hvis direkte utgående trafikk er forbudt når tunnelen er nede, er et vedlikeholdsunntak som stilltiende tillater alt en policyendring forkledd som en rettelse. Hold tunnelens eget endepunkt og bootstrap-behov i en separat kategori fra depotilgang, fordi de peker på forskjellige destinasjoner og feiler på forskjellige måter, så ett unntak kan ikke dekke det andre.

Verifiser uten å svekke kontrollene

Bruk omfanget gjennom brannmuren som allerede eier policyen, i stedet for å legge til en annen behandler fordi en guide brukte den. Kjør deretter en metadataoppdatering og én ekte pakketransaksjon under den vedlikeholdte policyen, og les utdata i stedet for bare exitstatus.

Vellykket transport er ikke tillatelse til å lempe på verifiseringen. Arkivautentisering og TLS-serverens identitet er separate garantier, og å slå av en av dem for å dempe en feil endrer hva du stoler på, ikke hva du kan nå.

Avslutt med å bevisst teste tilfellet uten tunnel. Å vite hvordan gatewayen oppfører seg uten tunnelen er en del av designet, å oppdage det under en driftsforstyrrelse er det ikke. Ta tunnelen ned, kjør metadataoppdateringen og bekreft at verten feiler på den måten du hadde tenkt i stedet for å falle stille tilbake til en åpen sti. Hold depot- og proxy-legitimasjon unna delte diagnostikker, og legg igjen et notat som navngir hvem som eier oppdateringsstien.