Uw VPN-gateway heeft nog steeds een manier nodig om updates te installeren

De tunnel werkt voor iedereen erachter, de gateway stuurt hun verkeer door, en toch kan de machine zelf geen beveiligingsupdate installeren. Dit is de gebruikelijke vorm van het probleem: de doorstuurrechten zijn aan clients gegeven, en de eigen uitgaande verbindingen van de gateway zijn nooit in het plan opgenomen. De pakketbeheerder opent zijn eigen sockets, vanaf de gateway, naar een repository die u waarschijnlijk nergens in het firewallbeleid hebt genoemd.

Een gateway hardenen is juist. Hem zo grondig hardenen dat hij geen patches meer ontvangt is een andere beslissing, en meestal een per ongeluk genomen beslissing.

Lokale uitvoer is geen doorsturen naar clients

Doorstuurregels gelden voor pakketten die ergens anders vandaan komen en via de gateway vertrekken. Het eigen updateverkeer van de gateway komt er nooit mee overeen; het wordt lokaal gegenereerd en volgt het uitvoerpad. Dat onderscheid verklaart een storing die onmogelijk lijkt terwijl clienttoegang perfect werkt.

Het verklaart ook een beleidsgat dat tests overleeft, omdat een snelle controle vanaf een laptop achter de tunnel bewijst dat de doorvoerketen werkt en niets zegt over de eigen verbindingen van de host. Behandel de gateway als twee subjecten: een router met een doorvoerketen en een host met een uitvoerketen. Beide hebben een standpunt nodig, en meestal wordt er maar één opgeschreven.

Benoem de fase die is mislukt

Updatefouten benoemen verschillende grenzen, en grijpen naar een poortregel voordat u leest welke is mislukt kost een middag. Een repositorynaam die niet resolveert is een resolvervraag, geen transportvraag.

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

Een time-out na een geslaagde opzoeking verschuift de vraag naar transport: welk adres, welke poort en welke geconfigureerde proxy de pakketbeheerder werkelijk heeft geprobeerd. Een TLS-verificatiefout is iets heel anders, en betekent dat de verbinding goed genoeg werkte om te onderhandelen. Een klacht over archiefauthenticatie is de vierde fase, en die gaat over ondertekende metadata in plaats van bereikbaarheid. Vier fasen, vier verschillende reparaties, en een ping beschrijft altijd maar één protocol dat geen enkele pakketbeheerder gebruikt.

Lees de bronnenlijst voordat u een regel toevoegt

Som de werkelijke bron-URI's en de effectieve proxyconfiguratie op in plaats van degene die u zich herinnert. Een regel voor gewone HTTP is nutteloos wanneer de bron HTTPS is, en een proxy die de shell kent kan onzichtbaar zijn voor een dienst die bij het opstarten met een andere omgeving start.

De documentatie over HTTP-transport van APT behandelt omgevings- en APT-specifieke proxyinstellingen, inclusief keuzes per host, en het HTTPS-transport heeft eigen verificatie-instellingen. Het pad dat een browser neemt en het pad dat de pakketbeheerder neemt zijn gescheiden paden, zelfs op dezelfde machine.

Let op naar welke families de bronnen resolven. Een regel die alleen IPv4 toestaat blijft falen op een host waarvan de bronnen een AAAA-record verkiezen, en de fout lijkt intermittent omdat hij afhangt van welk antwoord het eerst aankomt.

Kies één onderhoudspad en houd daaraan vast

Er zijn drie verdedigbare opties: onderhoudsverkeer via de tunnel, via een beheerde updateproxy of via een smalle directe uitzondering. Kies er bewust één en zorg dat de resolver het daarmee eens is, want een splitsing waarbij namen de ene kant op resolven en verbindingen de andere kant op gaan levert storingen op die niemand kan verklaren.

Wat u ook kiest, het mag geen onbeperkte terugvaloptie worden. Als direct uitgaand verkeer verboden is wanneer de tunnel uit ligt, is een onderhoudsuitzondering die stilzwijgend alles toestaat een beleidswijziging vermomd als oplossing. Houd het eigen eindpunt van de tunnel en de bootstrapbehoeften in een aparte categorie van repositorytoegang, omdat ze naar verschillende bestemmingen wijzen en op verschillende manieren falen, zodat de ene uitzondering de andere niet kan afdekken.

Verifieer zonder de controles te verzwakken

Pas de reikwijdte toe via de firewall die het beleid al bezit, in plaats van een tweede beheerder toe te voegen omdat één gids die gebruikte. Voer daarna een metadata-verversing en één echte pakkettransactie uit onder het onderhouden beleid, en lees de uitvoer in plaats van alleen de exitstatus.

Succes van het transport is geen toestemming om de verificatie te versoepelen. Archiefauthenticatie en de identiteit van de TLS-server zijn aparte garanties, en een van beide uitschakelen om een fout te dempen verandert wat u vertrouwt, niet wat u kunt bereiken.

Sluit af met het bewust testen van het geval zonder tunnel. Weten hoe de gateway zich zonder tunnel gedraagt hoort bij het ontwerp, het tijdens een storing ontdekken niet. Haal de tunnel naar beneden, voer de metadata-verversing uit en bevestig dat de host faalt op de manier die u bedoelde in plaats van stilzwijgend terug te vallen op een open pad. Houd repository- en proxyreferenties buiten gedeelde diagnostiek, en laat een notitie achter met de naam van wie het updatepad bezit.