Pachete VPN offline: întreabă ținta de ce are nevoie

Ai nevoie de clientul VPN ca să ajungi la rețeaua care în mod normal îi furnizează pachetele, iar asta este un cerc vicios drăguț. Descărcarea unui singur DEB OpenVPN pe o altă mașină se termină de obicei cu o a doua dependență lipsă, apoi cu o a treia, apoi cu o seară întreagă alergând după versiuni de biblioteci. Alternativa este să lași mașina deconectată să spună, în termenii ei, de ce are nevoie managerul ei de pachete. Tot ce urmează decurge din această inversare a cine întreabă.

Pentru sistemele din familia Debian, conversația aceea se face prin apt-offline, un flux de cerere și retur. Mediul său de rulare trebuie să fie prezent mai întâi pe țintă, instalat de pe medii aprobate sau dintr-un alt bootstrap administrat de administrator, pentru că niciun instrument nu se poate porni din nimic.

Pornește de la starea pachetelor țintei, nu de la cea a ajutorului

Înregistrează versiunea distribuției, arhitectura spațiului utilizator și sursele de pachete configurate ale țintei înainte de orice altceva. Aceste trei fapte decid ce implementare VPN și ce integrare cu desktopul sunt potrivite, iar ele sunt fapte pe care un ajutor conectat nu le poate furniza.

Ajutorul descarcă fișiere; nu devine baza dependențelor. Un laptop mai nou care are deja OpenVPN instalat are o stare a pachetelor complet diferită de țintă, așa că succesul lui nu dovedește nimic despre ce poate accepta ținta.

Hotărăște și ce vrei de fapt. Motorul VPN, un plugin de serviciu NetworkManager și un editor grafic sunt pachete separate, iar alegerea corectă depinde de versiune și de modul în care utilizatorul va administra conexiunea. Un server fără interfață are nevoie de motor și de un fișier de configurare; un desktop are nevoie de pluginul care lasă setările sale de rețea să stăpânească tunelul. Cererea setului greșit produce o instalare care reușește și o conexiune pe care nimeni nu o poate porni.

Două drumuri dus-întors, în această ordine

Manualul separă trei operații: generează o cerere pe sistemul deconectat, descarcă pe un ajutor conectat, importă înapoi pe țintă. Reîmprospătează metadatele depozitului țintei înainte de a cere pachete, pentru că cererea de pachete este construită din acele metadate, iar indicii vechi produc cereri pe care ajutorul nu le poate satisface.

Pe țintă, o comandă de administrator în forma apt-offline set vpn-meta.sig --update scrie cererea de reîmprospătare. Du fișierul la mașina conectată și descarcă un pachet arhivă cu apt-offline get vpn-meta.sig --bundle vpn-meta.zip. Adu pachetul arhivă înapoi și importă-l pe țintă cu apt-offline install vpn-meta.zip, din nou ca administrator.

Acum generează cererea de pachete din metadatele reîmprospătate, de exemplu apt-offline set vpn-deps.sig --install-packages openvpn, și repetă drumul cu un nume nou de pachet arhivă. Ține fiecare cerere împreună cu pachetul arhivă pe care l-a produs; un pachet generat pe metadate mai vechi nu este aceeași cerere, chiar și atunci când numele fișierelor par interschimbabile.

Adaugă pachetele de integrare doar când proiectarea le cere

Dacă desktopul ar trebui să administreze tunelul prin setările sale de rețea, cererea are nevoie de pluginul potrivit pe lângă motor. Include numele specifice de pachete pe care le oferă versiunea ta, nu o listă ținută minte dintr-o altă distribuție, și generează o cerere nouă ori de câte ori lista se schimbă. Fixarea versiunilor merită și ea o clipă de gândire: un pachet construit pentru o versiune mai nouă poate satisface numele și totuși poate eșua la rulare. Aici un set fix de patru pachete devine o povară, pentru că lista corectă este o proprietate a țintei și doar ținta o poate calcula.

Tot aici un set fix de patru pachete devine o povară. Lista corectă este o proprietate a țintei, iar ținta este singura mașină care o poate calcula corect.

Importarea unui pachet arhivă nu este instalarea VPN-ului

În ciuda numelui, operația de instalare depune date APT în mediul de administrare a pachetelor. Ea nu efectuează tranzacția de pachete. Finalizează și verifică instalarea APT reală a țintei din datele furnizate local, și citește rezultatul în loc să presupui că succesul ZIP-ului înseamnă că software-ul este prezent.

Dacă tranzacția aceea cere în continuare fișiere indisponibile, păstrează dependența lipsă sau eroarea de depozit concretă și generează următoarea cerere din ea. Nu înlocui un DEB dintr-o altă versiune și nu dezactiva verificările de checksum sau autentificarea depozitului ca să o forțezi. Manualul avertizează explicit împotriva săririi verificării fișierelor descărcate, și pe bună dreptate: un pachet neverificat este un rezultat mai rău decât o instalare eșuată.

Pachetele sunt doar prima jumătate

Instalarea software-ului este separată de obținerea endpointului, profilului, materialului de încredere și acreditarilor aprobate, fiecare putând avea propria predare controlată. Un set de pachete funcțional fără un profil valid nu se conectează la nimic.

Apoi ține calea de transfer offline vie pentru actualizările viitoare. A trata prima conexiune reușită drept sfârșitul întreținerii înseamnă că următoarea actualizare de securitate așteaptă până când cineva cu o mașină poate veni, și așa o rețea offline rămâne încet-încet ani în urmă.