Din VPN-gateway behöver fortfarande ett sätt att installera uppdateringar

Tunneln fungerar för alla bakom den, gatewayen vidarebefordrar deras trafik, och ändå kan maskinen själv inte installera en säkerhetsuppdatering. Det är den vanliga formen av problemet: vidarebefordringstillståndet gavs till klienterna, och gatewayens egna utgående anslutningar togs aldrig med i planen. Pakethanteraren öppnar sina egna sockets, från gatewayen, till ett förråd som du förmodligen inte har namngett någonstans i brandväggspolicyn.

Att låsa ner en gateway är korrekt. Att låsa ner den så grundligt att den slutar ta emot patchar är ett annat beslut, och oftast ett oavsiktligt sådant.

Lokal utdata är inte klientvidarebefordran

Vidarebefordringsregler styr paket som kommer från någon annanstans och lämnar genom gatewayen. Gatewayens egen uppdateringstrafik matchar dem aldrig; den genereras lokalt och går genom utgångsvägen. Den skillnaden förklarar ett fel som verkar omöjligt medan klientåtkomsten fungerar perfekt.

Den förklarar också en lucka i policyn som överlever tester, eftersom en snabb kontroll från en bärbar dator bakom tunneln bevisar att vidarebefordringskedjan fungerar och inte säger något om värdens egna anslutningar. Behandla gatewayen som två subjekt: en router med en vidarebefordringskedja och en värd med en utgångskedja. Båda behöver en åsikt, och bara en av dem brukar skrivas ner.

Namnge steget som misslyckades

Uppdateringsfel namnger olika gränser, och att gripa efter en portregel innan man läser vilken som misslyckades kostar en eftermiddag. Ett förrådsnamn som inte kan slås upp är en resolverfråga, inte en transportfråga.

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 en lyckad uppslagning flyttar frågan till transport: vilken adress, vilken port och vilken konfigurerad proxy som pakethanteraren faktiskt försökte med. Ett TLS-verifieringsfel är något helt tredje, och det betyder att anslutningen fungerade tillräckligt bra för att förhandla. Ett klagomål om arkivautentisering är det fjärde steget, och det handlar om signerade metadata snarare än nåbarhet. Fyra steg, fyra olika reparationer, och en ping beskriver alltid bara ett protokoll som ingen pakethanterare använder.

Läs källlistan innan du lägger till en regel

Lista de faktiska käll-URI:erna och den effektiva proxykonfigurationen i stället för dem du minns. En regel skriven för vanlig HTTP är värdelös när källan är HTTPS, och en proxy som skalet känner till kan vara osynlig för en tjänst som startas vid uppstart med en annan miljö.

APT:s dokumentation för HTTP-transport täcker miljö- och APT-specifika proxyinställningar, inklusive val per värd, och dess HTTPS-transport har egna verifieringsinställningar. Den väg en webbläsare tar och den väg pakethanteraren tar är separata vägar, även på samma maskin.

Notera vilka familjer källorna slår upp till. En regel som bara tillåter IPv4 kommer att fortsätta misslyckas på en värd vars källor föredrar en AAAA-post, och felet verkar intermittent eftersom det beror på vilket svar som kommer först.

Välj en underhållsväg och håll fast vid den

Det finns tre försvarbara alternativ: underhållstrafik genom tunneln, genom en hanterad uppdateringsproxy eller genom ett smalt direkt undantag. Välj ett medvetet och se till att resolvern håller med, eftersom en delning där namn slås upp åt ena hållet och anslutningar går åt det andra ger fel som ingen kan förklara.

Vad du än väljer får det inte bli en obegränsad reservlösning. Om direkt utgående trafik är förbjuden när tunneln är nere, är ett underhållsundantag som tyst tillåter allt en policyändring förklädd till en fix. Håll tunnelns egen endpoint och bootstrapbehov i en separat kategori från förrådsåtkomst, eftersom de pekar på olika destinationer och misslyckas på olika sätt, så ett undantag kan inte täcka det andra.

Verifiera utan att försvaga kontrollerna

Tillämpa omfånget genom brandväggen som redan äger policyn i stället för att lägga till en andra hanterare eftersom en guide använde den. Kör sedan en metadatauppdatering och en riktig pakettransaktion under den underhållna policyn, och läs utdata i stället för bara slutstatusen.

Lyckad transport är inte tillstånd att lätta på verifieringen. Arkivautentisering och TLS-serverns identitet är separata garantier, och att stänga av någon av dem för att tysta ett fel ändrar vad du litar på, inte vad du kan nå.

Avsluta med att medvetet testa fallet utan tunnel. Att veta hur gatewayen beter sig utan sin tunnel är en del av designen, att upptäcka det under ett avbrott är det inte. Ta ner tunneln, kör metadatauppdateringen och bekräfta att värden misslyckas på det sätt du avsåg i stället för att tyst falla tillbaka till en öppen väg. Håll förråds- och proxyuppgifter borta från delade diagnoser, och lämna en anteckning som namnger vem som äger uppdateringsvägen.