Posodobitev prehoda VPN ne uspe: preberite stopnjo, preden odprete izhod

Zavračanje namestitve varnostnih posodobitev je le en slab teden oddaljeno od tega, da postanete nekomu drugemu težava, in prehod, ki spusti odjemalce, je najlažje mesto za razvoj te navade. Običajni vzrok ni manjkajoča pot, ampak manjkajoča odločitev: nihče ni povedal, kako naj gostitelj sam doseže shrambo, ko je posredovanje odjemalcev namerno ozko. To odločitev je treba sprejeti izrecno in mora biti ožja od izklopa izhodne politike za eno popoldne.

Štiri stopnje, štirje različni lastniki

Neuspeh posodobitve je poimenovana stopnja, ne glede na to, ali sporočilo to pove, in vsaka stopnja pripada drugemu lastniku. Ime, ki se ne razreši, je vprašanje za razreševalnik. Povezava, ki ji poteče čas, je vprašanje za prenos, proxy ali oddaljeni konec. Napaka identitete TLS je vprašanje zaupanja, in zavrnjeni metapodatki arhiva so vprašanje podpisa. Štiri stopnje, štirje lastniki, in pravilo vrat vedno odgovori le na eno od njih.

Ping in razreševanje imen sta dva preizkusa, po katerih ljudje najprej posežejo, in oba odgovarjata na vprašanja, ki jih nihče ni postavil. Odgovor echo uporablja drug protokol kot povezava do shrambe, in uspešno iskanje se ustavi pri razreševanju imen, ne da bi preizkusilo pridobivanje. Oba lahko uspeta, medtem ko prava transakcija ne uspe, in oba lahko ne uspeta iz razlogov, ki nimajo zveze s potjo.

Preberite pot, ki jo upravitelj dejansko ubere

Preverite nastavljene izvorne URI-je in dejansko ureditev proxyja, namesto da bi katero koli od tega predpostavljali. Pravilo, napisano za navaden HTTP, ni popravilo, ko shramba govori HTTPS, in organizacija, ki zahteva proxy, je pot že izbrala. Upravitelji paketov upoštevajo okoljske spremenljivke in lastno konfiguracijo, in nastavitve, specifične za gostitelja, lahko preglasijo globalne. Kar počne interaktivni brskalnik, ni nujno tisto, kar počne upravitelj.

apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxy

Dokumentacija prenosa APT opisuje, katere nastavitve veljajo za katero shemo URI in kako se zapisujejo izbire, specifične za gostitelja. Shranite izpis ukazov skupaj s prijavo, ker loči težavo s proxyjem od manjkajoče poti hitreje kot kakršno koli število rezultatov pinga. Zapišite natančen cilj, vrata in protokol, ki jih upravitelj poskuša, in pustite, da sprememba požarnega zidu temelji na tem zapisu, ne na ugibani zrcalni naslov, ki zastara v nekaj mesecih.

Izberite politiko vzdrževanja, ne izjeme

Tri politike so zagovarljive: vzdrževanje skozi tunel, vzdrževanje skozi upravljani posodobitveni proxy ali vzdrževanje skozi ozko pooblaščeno neposredno pot. Vsaka od njih predpostavlja ustrezno ureditev razreševalnika. Kar ni zagovarljivo, je izjema, ki tiho postane neomejena rezervna pot vsakič, ko tunel pade.

Zapišite izbrano politiko skupaj z lastnikom, ker bo naslednji operater našel pravilo in ne razlogov za njim. Uveljavite dovoljenje skozi obstoječi požarni zid in lastnika omrežja, namesto da bi izpraznili pravila ali dodali drugega upravitelja politik za enega gostitelja. Pokrijte družine naslovov in storitvene končne točke, ki jih uporablja pravi vir, in seznam pregledajte, ko se shramba preseli.

Preverjajte, ne da bi oslabili zaupanje

Uspešen prenos ni dovoljenje za omilitev preverjanja: overjanje arhiva in identiteta strežnika TLS sta dve ločeni preverjanji, in izklop katere koli od njiju povzroči, da napaka izgine, hkrati pa spremeni, kaj bo gostitelj sprejel. Prestrezaški proxy je odločitev o zaupanju lastnika omrežja, ne razlog za izklop preverjanja lokalno, in poverilnice shrambe ne spadajo v deljeno diagnostiko, ker je podroben dnevnik najlažje mesto za njihovo razkritje.

Sprejmite spremembo s kontroliranim pridobivanjem metapodatkov in nato z eno odobreno transakcijo paketa, nato preizkusite, kaj se zgodi, ko tunel pade. Pot vzdrževanja, ki se med izpadom tiho razširi, je slabša od tiste, ki ne uspe zaprta, in rezultat bi moral biti posodobitvena pot z imenovanim lastnikom in omejenim obsegom.