Waarom 'n VPN-gids nie vir die nodus agter die inskrywing kan instaan nie
'n Inskrywing beskryf 'n verbinding en die gids wat dit gepubliseer het. Versameling en bewaring hoort by die operateur, wat 'n ander party kan wees.
Gidsinskrywings wat 'n gasheernaam, 'n land en 'n stel protokolle lys, is getuienis oor konnektiwiteit, nie oor wat die masjien aan die ander kant aanteken nie. Die beslissing wat hier saak maak, is nie of 'n mens inskrywings in die algemeen moet vertrou nie. Dit is watter party in 'n posisie is om die vraag te beantwoord wat jy eintlik vra.
Vier partye agter een inskrywing
Skei die rolle voordat jy enige belofte lees. Die gids publiseer die inskrywing, die sagtewareprojek lewer die protokolimplementering, die hostverskaffer lewer die masjien en die netwerk, en die nodusoperateur stel die diens op. Enige van die vier kan 'n ander organisasie wees, en elkeen kan net vir sy eie deel praat.
Daardie verdeling verduidelik waarom 'n stelling waar kan wees en tog nutteloos. 'n Ontwikkelaar wat dokumenteer dat die protokol nie datalading aanteken nie, sê niks oor 'n operateur wat breedvoerige verbindingslogboeke op 'n afloser geaktiveer het nie. Albei stellings kan sonder teenspraak saam bestaan. Dit is juis waarom die vraag aan 'n genoemde party gerig moet word.
Sommige dienste bedryf hul eie eindpunte, en dan kom die inskrywing en die beleid van dieselfde party. Dit is 'n sterker posisie, maar dit moet steeds vasgestel word eerder as uit die formaat van die bladsy afgelei word. Vra vir die verklaring, en kyk of dit die diens noem waarheen die inskrywing wys.
Vra vir die rekord wat by die bewering pas
'n Bewering oor versameling het 'n dokument nodig wat die stelsel, die datakategorie en die tydperk noem. 'n Bewering oor bewaring het 'n getal en 'n omvang nodig. 'n Bewering oor onafhanklikheid het 'n beskrywing nodig van wie wat besit, nie 'n byvoeglike naamwoord nie.
| 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 |
Vrywilligersprojekte is dikwels die duidelikste voorbeeld, want sommige publiseer uitdruklike logvereistes vir die nodusse wat hulle aanvaar. Daardie dokument is primêre getuienis oor die projek se reëls, en dit is steeds nie getuienis oor 'n individuele operateur wat dit geïgnoreer het nie.
Oudits volg dieselfde logika op 'n ander skaal. 'n Verslag wat 'n spesifieke ontplooiing gedurende 'n spesifieke tydvenster ondersoek het, is nuttig binne daardie grens. Oor elke onafhanklike instansie van dieselfde sagteware uitgestrek, word dit 'n waarborg wat niemand uitgereik het nie. Lees die omvangparagraaf voordat jy die gevolgtrekking lees.
Wanneer 'n verskaffer se privaatheidsverklaring sy eie diens dek, lees dit as daardie verskaffer se stelling oor sy eie stelsels. Om dit te hergebruik om 'n derdeparty-afloser te beskryf, is 'n kategorie-fout, selfs wanneer die protokol identies is.
Besluit wat jy met elke opsie koop
'n Openbare nodus koop bereikbaarheid en verskeidenheid teen die prys van verantwoordbaarheid. 'n Operateur wat jou niks verskuldig is nie, kan verdwyn, die opstelling verander of rekords sonder kennisgewing hou, en jou verhaal is beperk tot om eindpunte te ruil. Daardie ruil is vir sommige take aanvaarbaar en vir ander nie.
'n Betaalde diens koop 'n teenparty met 'n gepubliseerde beleid en iets om te verloor. Dit koop nie 'n tegniese waarborg nie, en dit verwyder nie die noodsaak om die beleid te lees nie, maar 'n genoemde organisasie met 'n bewaringsverklaring is makliker om te evalueer as 'n anonieme afloser.
Die beslissingsreël wat albei gevalle oorleef, is om die getuienis by die risiko te pas. As die taak 'n roterende eindpunt verdra, is die gids 'n doeltreffende instrument. As dit van 'n spesifieke databehandelingsbelofte afhang, is net die party wat daardie belofte kan maak, relevant, en die gids is 'n roetegerief eerder as 'n versekering.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'Die een opdrag hierbo is die moeite werd om te hardloop, want dit skei twee vrae skoon. Dit wys die adres wat jou verkeer werklik gebruik het, wat 'n konnektiwiteitsfeit is, en dit sê niks oor wat die operateur van daardie adres met die verbindingsmetadata gedoen het nie.
Hou die vrae aan die kliëntekant apart
Operateurbeleid is een laag, en die sekuriteit van wat jy oor die tonnel doen, is 'n ander. HTTPS by die bestemming, sessiehantering in die blaaier en die sterkte van die rekening waarmee jy aangemeld het, bly jou beheer, en 'n toegeeflike afloser verswak dit nie terwyl 'n uitstekende een dit nie versterk nie.
Daardie skeiding voorkom twee algemene foute. Om 'n streng operateurbeleid as rede te sien om HTTPS oor te slaan, is een, en om 'n werkende HTTPS-verbinding as rede te sien om te ignoreer wie die afloser bedryf, is die ander. Albei foute val twee lae in een saam en stry dan oor die verkeerde een.
'n Kort skriftelike beoordeling hanteer albei. Noem die party wat elke belofte maak, heg die dokument aan wat dit ondersteun, en noteer die datum. Besluit dan of die taak die sterker bewering nodig het of bloot 'n werkende pad.
Die inskrywing het sy werk gedoen sodra dit jou gesê het waar jy kon aansluit. Die res van die vraag hoort by wie daardie eindpunt bedryf, en die eerlike antwoord is dikwels dat jy dit nie kan weet nie en daarvolgens moet kies.