Din VPN-gateway har stadig brug for en måde at installere opdateringer
En låst gateway skal stadig kunne nå sine repositories. Find ud af, hvilken fase der fejlede, og tillad derefter netop den sti i stedet for at åbne udgående trafik.
Tunnelen virker for alle bag den, gatewayen videresender deres trafik, og alligevel kan maskinen selv ikke installere en sikkerhedsopdatering. Det er den sædvanlige form for problemet: videresendelsestilladelsen blev givet til klienterne, og gatewayens egne udgående forbindelser blev aldrig inkluderet i planen. Pakkehåndteringen åbner sine egne sockets, fra gatewayen, til et repository, som du sandsynligvis ikke har navngivet nogen steder i firewallpolitikken.
Det er rigtigt at stramme en gateway. At stramme den så grundigt, at den holder op med at modtage patches, er en anden beslutning, og som regel en tilfældig en.
Lokal output er ikke klientvideresendelse
Videresendelsesregler gælder for pakker, der ankommer fra et andet sted og forlader gennem gatewayen. Gatewayens egen opdateringstrafik matcher dem aldrig; den genereres lokalt og går gennem outputstien. Den forskel forklarer en fejl, der virker umulig, mens klientadgang fungerer perfekt.
Den forklarer også et hul i politikken, der overlever test, fordi et hurtigt tjek fra en bærbar computer bag tunnelen beviser, at videresendelseskæden virker, og intet siger om værtens egne forbindelser. Betragt gatewayen som to subjekter: en router med en videresendelseskæde og en vært med en outputkæde. Begge har brug for en holdning, og kun én af dem bliver normalt skrevet ned.
Navngiv den fase, der fejlede
Opdateringsfejl navngiver forskellige grænser, og at gribe efter en portregel, før man læser hvilken der fejlede, koster en eftermiddag. Et repositorynavn, der ikke kan opløses, er et resolver-spørgsmål, ikke et transportspørgsmå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 timeout efter et vellykket opslag flytter spørgsmålet til transport: hvilken adresse, hvilken port og hvilken konfigureret proxy pakkehåndteringen faktisk forsøgte. En TLS-verifikationsfejl er noget helt tredje, og den betyder, at forbindelsen fungerede godt nok til at forhandle. En klage over arkivgodkendelse er den fjerde fase, og den handler om signerede metadata i stedet for tilgængelighed. Fire faser, fire forskellige reparationer, og en ping beskriver altid kun én protokol, som ingen pakkehåndtering bruger.
Læs kildelisten, før du tilføjer en regel
List de faktiske kilde-URI'er og den effektive proxykonfiguration i stedet for dem, du husker. En regel skrevet til almindelig HTTP er ubrugelig, når kilden er HTTPS, og en proxy, som shellen kender, kan være usynlig for en tjeneste, der startes ved opstart med et andet miljø.
APT's dokumentation for HTTP-transport dækker miljø- og APT-specifikke proxyindstillinger, inklusive valg pr. host, og dens HTTPS-transport har sine egne verifikationsindstillinger. Den sti, en browser tager, og den sti, pakkehåndteringen tager, er adskilte stier, selv på samme maskine.
Bemærk, hvilke familier kilderne opløses til. En regel, der kun tillader IPv4, vil fortsat fejle på en vært, hvis kilder foretrækker en AAAA-post, og fejlen virker periodisk, fordi den afhænger af, hvilket svar der ankommer først.
Vælg én vedligeholdelsesvej og hold fast ved den
Der findes tre forsvarlige muligheder: vedligeholdelsestrafik gennem tunnelen, gennem en administreret opdateringsproxy eller gennem en smal direkte undtagelse. Vælg bevidst én, og sørg for, at resolveren er enig, fordi en opdeling, hvor navne opløses den ene vej og forbindelser går den anden, giver fejl, som ingen kan forklare.
Uanset hvad du vælger, må det ikke blive en ubegrænset tilbagefaldsløsning. Hvis direkte udgående trafik er forbudt, når tunnelen er nede, er en vedligeholdelsesundtagelse, der stiltiende tillader alt, en politikændring forklædt som en rettelse. Hold tunnelens eget endpoint og bootstrap-behov i en separat kategori fra repository-adgang, fordi de peger på forskellige destinationer og fejler på forskellige måder, så én undtagelse ikke kan dække den anden.
Bekræft uden at svække kontrollerne
Anvend omfanget gennem den firewall, der allerede ejer politikken, i stedet for at tilføje en anden manager, fordi en guide brugte den. Kør derefter en metadataopdatering og én rigtig pakketransaktion under den vedligeholdte politik, og læs outputtet i stedet for kun exitstatus.
Vellykket transport er ikke tilladelse til at lempe verifikationen. Arkivgodkendelse og TLS-serverens identitet er separate garantier, og at deaktivere en af dem for at bringe en fejl til tavshed ændrer, hvad du stoler på, ikke hvad du kan nå.
Afslut med bevidst at teste tilfældet uden tunnel. At vide, hvordan gatewayen opfører sig uden sin tunnel, er en del af designet, at opdage det under en afbrydelse er ikke. Tag tunnelen ned, kør metadataopdateringen, og bekræft, at værten fejler på den tilsigtede måde i stedet for stiltiende at falde tilbage til en åben sti. Hold repository- og proxyoplysninger ude af delte diagnoser, og efterlad en note, der navngiver, hvem der ejer opdateringsstien.