De ce un director de VPN nu poate garanta pentru nodul din spatele lui
O înregistrare descrie o conexiune și directorul care a publicat-o. Colectarea și păstrarea aparțin operatorului, care poate fi o altă parte.
Înregistrările din director care listează un nume de gazdă, o țară și un set de protocoale sunt dovezi despre conectivitate, nu despre ce înregistrează mașina de la celălalt capăt. Decizia care contează aici nu este dacă să ai încredere în liste în general. Este care parte este în măsură să răspundă la întrebarea pe care o pui de fapt.
Patru părți în spatele unei înregistrări
Separați rolurile înainte de a citi orice promisiune. Directorul publică înregistrarea, proiectul software furnizează implementarea protocolului, furnizorul de găzduire furnizează mașina și rețeaua, iar operatorul nodului configurează serviciul. Oricare dintre cele patru poate fi o altă organizație, iar fiecare poate vorbi doar despre partea sa.
Această separare explică de ce o afirmație poate fi adevărată și totuși inutilă. Un dezvoltator care documentează că protocolul nu înregistrează conținutul nu spune nimic despre un operator care a activat jurnalizarea detaliată a conexiunilor pe un releu. Ambele afirmații pot coexista fără contradicție. Tocmai de aceea întrebarea trebuie adresată unei părți numite.
Unele servicii își operează propriile puncte terminale, iar atunci înregistrarea și politica vin de la aceeași parte. Este o poziție mai puternică, dar trebuie totuși stabilită, nu presupusă din formatul paginii. Cereți declarația și verificați dacă numește serviciul către care indică înregistrarea.
Cereți documentul care corespunde afirmației
O afirmație despre colectare necesită un document care numește sistemul, categoria de date și perioada. O afirmație despre păstrare necesită un număr și o sferă. O afirmație despre independență necesită o descriere a cine deține ce, nu un adjectiv.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
Proiectele de voluntariat sunt adesea cel mai clar exemplu, pentru că unele publică cerințe explicite de jurnalizare pentru nodurile pe care le acceptă. Acel document este dovadă primară despre regulile proiectului și încă nu este dovadă despre un operator individual care le-a ignorat.
Auditurile urmează aceeași logică la altă scară. Un raport care a examinat o implementare anume într-o fereastră anume este util în acea limită. Întins peste fiecare instanță independentă a aceluiași software, devine o garanție pe care nimeni nu a emis-o. Citiți paragraful despre sferă înainte de a citi concluzia.
Când declarația de confidențialitate a unui furnizor îi acoperă propriul serviciu, citiți-o ca declarația acelui furnizor despre propriile sisteme. Reutilizarea ei pentru a descrie un releu al unei terțe părți este o eroare de categorie, chiar și când protocolul este identic.
Decideți ce cumpărați cu fiecare opțiune
Un nod public cumpără accesibilitate și varietate cu prețul responsabilității. Un operator care nu vă datorează nimic poate dispărea, schimba configurația sau păstra înregistrări fără notificare, iar soluția dumneavoastră se limitează la schimbarea punctelor terminale. Acest schimb este acceptabil pentru unele sarcini și nu pentru altele.
Un serviciu plătit cumpără o contraparte cu o politică publicată și cu ceva de pierdut. Nu cumpără o garanție tehnică și nu elimină nevoia de a citi politica, dar o organizație numită cu o declarație de păstrare este mai ușor de evaluat decât un releu anonim.
Regula de decizie care rezistă în ambele cazuri este să potrivești dovada cu riscul. Dacă sarcina tolerează un punct terminal schimbător, directorul este un instrument eficient. Dacă depinde de o promisiune anume despre prelucrarea datelor, este relevantă doar partea care poate face acea promisiune, iar directorul este o comoditate de rutare, nu o asigurare.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'Comanda de mai sus merită rulată pentru că separă curat două întrebări. Arată adresa pe care traficul dumneavoastră a folosit-o de fapt, ceea ce este un fapt despre conectivitate, și nu spune nimic despre ce a făcut operatorul acelei adrese cu metadatele conexiunii.
Țineți separate întrebările din partea clientului
Politica operatorului este un strat, iar securitatea a ceea ce faceți prin tunel este altul. HTTPS la destinație, gestionarea sesiunilor în browser și tăria contului în care v-ați autentificat rămân sub controlul dumneavoastră, iar un releu permisiv nu le slăbește, după cum unul excelent nu le întărește.
Această separare împiedică două greșeli obișnuite. Să consideri o politică strictă a operatorului drept motiv pentru a sări peste HTTPS este una, iar să consideri o conexiune HTTPS funcțională drept motiv pentru a ignora cine operează releul este cealaltă. Ambele greșeli topesc două straturi într-unul și apoi discută despre cel greșit.
O scurtă evaluare scrisă le rezolvă pe amândouă. Numiți partea care face fiecare promisiune, atașați documentul care o susține și notați data. Apoi decideți dacă sarcina are nevoie de afirmația mai puternică sau doar de o cale funcțională.
Înregistrarea și-a făcut treaba când v-a spus unde vă puteți conecta. Restul întrebării aparține celui care operează acel punct terminal, iar răspunsul onest este adesea că nu puteți ști și ar trebui să alegeți în consecință.