Gateway-ul VPN are în continuare nevoie de o cale de a instala actualizări

Tunelul funcționează pentru toți cei din spatele lui, gateway-ul le transmite traficul și totuși mașina în sine nu poate instala o actualizare de securitate. Aceasta este forma obișnuită a problemei: permisiunea de redirecționare a fost acordată clienților, iar conexiunile de ieșire proprii ale gateway-ului nu au fost niciodată incluse în plan. Managerul de pachete își deschide propriile socketuri, de la gateway, către un depozit pe care probabil nu l-ați numit nicăieri în politica firewall-ului.

Blocarea unui gateway este corectă. Blocarea lui atât de temeinic încât să nu mai primească patch-uri este o altă decizie, și de obicei una accidentală.

Ieșirea locală nu este redirecționarea clienților

Regulile de redirecționare guvernează pachetele care sosesc de altundeva și pleacă prin gateway. Traficul de actualizare propriu al gateway-ului nu le întâlnește niciodată; este generat local și parcurge calea de ieșire. Această distincție explică o defecțiune care pare imposibilă în timp ce accesul clienților funcționează perfect.

Explică și o lacună de politică ce supraviețuiește testelor, pentru că o verificare rapidă de pe un laptop din spatele tunelului demonstrează că lanțul de redirecționare funcționează și nu spune nimic despre conexiunile proprii ale gazdei. Tratați gateway-ul ca doi subiecți: un router cu un lanț de redirecționare și o gazdă cu un lanț de ieșire. Ambele au nevoie de o poziție, și de obicei doar una dintre ele este consemnată.

Numiți etapa care a eșuat

Erorile de actualizare numesc limite diferite, iar căutarea unei reguli de port înainte de a citi care dintre ele a eșuat pierde o după-amiază. Un nume de depozit care nu se rezolvă este o întrebare de resolver, nu o întrebare de transport.

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

Un timeout după o rezolvare reușită mută întrebarea către transport: ce adresă, ce port și ce proxy configurat a încercat de fapt managerul de pachete. O eroare de verificare TLS este un al treilea lucru, complet diferit, și înseamnă că conexiunea a funcționat suficient de bine pentru a negocia. O reclamație privind autentificarea arhivei este a patra etapă, și se referă la metadate semnate, nu la accesibilitate. Patru etape, patru reparații diferite, iar un ping descrie întotdeauna doar un protocol pe care niciun manager de pachete nu îl folosește.

Citiți lista surselor înainte de a adăuga o regulă

Enumerați URI-urile reale ale surselor și configurația efectivă de proxy, nu pe cele pe care vi le amintiți. O regulă scrisă pentru HTTP simplu este inutilă când sursa este HTTPS, iar un proxy pe care shell-ul îl cunoaște poate fi invizibil pentru un serviciu pornit la boot cu un alt mediu.

Documentația transportului HTTP din APT acoperă setările de proxy de mediu și specifice APT, inclusiv alegerile pe gazdă, iar transportul său HTTPS are propriile setări de verificare. Calea unui browser și calea managerului de pachete sunt căi separate, chiar și pe aceeași mașină.

Observați în ce familii se rezolvă sursele. O regulă care permite doar IPv4 va continua să eșueze pe o gazdă ale cărei surse preferă o înregistrare AAAA, iar eroarea pare intermitentă pentru că depinde de care răspuns sosește primul.

Alegeți o singură cale de întreținere și țineți-vă de ea

Există trei opțiuni justificabile: trafic de întreținere prin tunel, printr-un proxy de actualizare administrat sau printr-o excepție directă îngustă. Alegeți una deliberat și faceți resolverul să fie de acord, pentru că o separare în care numele se rezolvă într-un fel și conexiunile merg în altul produce defecțiuni pe care nimeni nu le poate explica.

Orice ați alege, nu trebuie să devină o soluție de rezervă nelimitată. Dacă traficul de ieșire direct este interzis când tunelul este căzut, o excepție de întreținere care permite în tăcere totul este o schimbare de politică deghizată în remediere. Țineți punctul final propriu al tunelului și nevoile de bootstrap într-o categorie separată de accesul la depozite, pentru că indică destinații diferite și eșuează în moduri diferite, așa că o excepție nu o poate acoperi pe cealaltă.

Verificați fără a slăbi controalele

Aplicați domeniul prin firewall-ul care deține deja politica, în loc să adăugați un al doilea manager pentru că un ghid l-a folosit. Apoi rulați o reîmprospătare a metadatelor și o tranzacție reală de pachete sub politica întreținută, și citiți ieșirea, nu doar codul de ieșire.

Un transport reușit nu este permisiunea de a relaxa verificarea. Autentificarea arhivei și identitatea serverului TLS sunt garanții separate, iar dezactivarea oricăreia dintre ele pentru a reduce la tăcere o eroare schimbă ceea în ce ai încredere, nu ceea ce poți atinge.

Încheiați testând deliberat cazul fără tunel. Să știi cum se comportă gateway-ul fără tunelul său face parte din proiectare, să descoperi asta în timpul unei întreruperi nu. Opriți tunelul, rulați reîmprospătarea metadatelor și confirmați că gazda eșuează în modul dorit, în loc să revină în tăcere la o cale deschisă. Țineți acreditările depozitelor și ale proxy-ului în afara diagnosticelor partajate și lăsați o notă cu cine deține calea de actualizare.