Per què un directori de VPN no pot respondre pel node que hi ha darrere
Una fitxa descriu una connexió i el directori que la va publicar. La recollida i la retenció corresponen a l'operador, que pot ser una altra part.
Les entrades de directori que llisten un nom d'amfitrió, un país i un conjunt de protocols són evidència sobre la connectivitat, no sobre què registra la màquina de l'altre costat. La decisió que importa aquí no és si cal confiar en els llistats en general. És quina part està en posició de respondre la pregunta que realment feu.
Quatre parts darrere d'una entrada
Separeu els papers abans de llegir cap promesa. El directori publica l'entrada, el projecte de programari aporta la implementació del protocol, el proveïdor d'allotjament aporta la màquina i la xarxa, i l'operador del node configura el servei. Qualsevol de les quatre pot ser una altra organització, i cadascuna només pot parlar de la seva part.
Aquesta divisió explica per què una afirmació pot ser certa i tot i així inútil. Un desenvolupador que documenta que el protocol no registra la càrrega útil no diu res sobre un operador que ha activat el registre detallat de connexions en un repetidor. Totes dues afirmacions poden coexistir sense contradicció. És precisament per això que la pregunta s'ha d'adreçar a una part identificada.
Alguns serveis operen les seves pròpies terminacions i aleshores l'entrada i la política vénen de la mateixa part. És una posició més forta, però encara cal establir-la en lloc de suposar-la pel format de la pàgina. Demaneu la declaració i comproveu que anomena el servei al qual apunta l'entrada.
Demaneu el registre que correspon a l'afirmació
Una afirmació sobre recollida necessita un document que anomeni el sistema, la categoria de dades i el període. Una afirmació sobre retenció necessita un número i un abast. Una afirmació sobre independència necessita una descripció de qui posseeix què, no un adjectiu.
| 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 |
Els projectes voluntaris sovint són l'exemple més clar, perquè alguns publiquen requisits explícits de registre per als nodes que accepten. Aquest document és evidència primària sobre les regles del projecte, i encara no és evidència sobre un operador individual que les va ignorar.
Les auditories segueixen la mateixa lògica a una altra escala. Un informe que va examinar un desplegament concret durant una finestra concreta és útil dins d'aquesta frontera. Estirat sobre cada instància independent del mateix programari, es converteix en una garantia que ningú no va emetre. Llegiu el paràgraf d'abast abans de llegir la conclusió.
Quan la declaració de privadesa d'un proveïdor cobreix el seu propi servei, llegiu-la com la declaració d'aquest proveïdor sobre els seus propis sistemes. Reutilitzar-la per descriure un repetidor de tercers és un error de categoria, encara que el protocol sigui idèntic.
Decidiu què compreu amb cada opció
Un node públic compra abast i varietat a canvi de responsabilitat. Un operador que no us deu res pot desaparèixer, canviar la configuració o guardar registres sense avís, i el vostre recurs es limita a canviar de terminació. Aquest intercanvi és acceptable per a algunes tasques i no per a d'altres.
Un servei de pagament compra una contrapart amb una política publicada i alguna cosa a perdre. No compra una garantia tècnica i no elimina la necessitat de llegir la política, però una organització identificada amb una declaració de retenció és més fàcil d'avaluar que un repetidor anònim.
La regla de decisió que sobreviu als dos casos és fer correspondre l'evidència al risc. Si la tasca tolera una terminació rotatòria, el directori és una eina eficient. Si depèn d'una promesa concreta de tractament de dades, només és rellevant la part que pot fer aquesta promesa, i el directori és una comoditat d'encaminament, no una garantia.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'L'ordre anterior val la pena d'executar perquè separa netament dues preguntes. Mostra l'adreça que el vostre trànsit va fer servir realment, cosa que és un fet de connectivitat, i no diu res sobre què va fer l'operador d'aquesta adreça amb les metadades de la connexió.
Manteniu separades les preguntes del costat del client
La política de l'operador és una capa, i la seguretat del que feu pel túnel és una altra. HTTPS a la destinació, la gestió de la sessió al navegador i la força del compte amb què heu entrat continuen sent els vostres controls, i un repetidor permissiu no els debilita mentre que un d'excel·lent no els reforça.
Aquesta separació evita dos errors habituals. Considerar que una política estricta de l'operador és un motiu per saltar-se HTTPS és un, i considerar que una connexió HTTPS funcional és un motiu per ignorar qui opera el repetidor és l'altre. Tots dos errors ajunten dues capes en una i després discuteixen sobre la capa equivocada.
Una avaluació escrita breu resol les dues coses. Anomeneu la part que fa cada promesa, adjunteu el document que la sosté i anoteu la data. Després decidiu si la tasca necessita l'afirmació més forta o només un camí funcional.
L'entrada va fer la seva feina quan us va dir on us podíeu connectar. La resta de la pregunta pertany a qui opera aquesta terminació, i la resposta honesta sovint és que no ho podeu saber i que heu de triar en conseqüència.