Onion-diens teenoor VPN-diens: verskillende toegangsmodelle

’n Onion-diens en ’n diens wat net oor VPN bereikbaar is, word as twee variante van dieselfde idee beskryf: versteek die poort, deel die geheime adres. Hulle verskil in waaraan die adres gebind is, wie dit kan bereik en wat moet gebeur voordat ’n versoek aankom. Die een is ’n ontmoetingspunt binne Tor; die ander is ’n roete binne ’n privaat netwerk. Om hulle as uitruilbaar te behandel, lewer ontwerpe op wat nóg privaat nóg onderhoudbaar is.

Die mite: albei ontwerpe is net ’n verborge deur

Die gedeelde eienskap is werklik maar dun: geen van die twee ontwerpe plaas die administratiewe koppelvlak op ’n direk bereikbare openbare poort nie. Alles daarna verskil. ’n Onion-adres word uit die diens se eie sleutel afgelei, so die naam is aan ’n identiteit gebind; ’n VPN-adres is net ’n adres binne ’n netwerk waartoe jy toegelaat is. Die een versteek die diens binne ’n oorlaag, die ander laat jou toe tot ’n privaat topologie. Om die tweede as ’n sinoniem vir die eerste te sien, is waar die verwarring begin.

Nie een van die eienskappe is ’n sekuriteitsmaatreël vir die toepassing self nie. ’n Verborge ligging pleister nie die sagteware agter hom nie, en ’n privaat roete voeg nie verifikasie by die aanmeldbladsy nie. Albei ontwerpe het steeds die toepassing se eie toestemmings nodig, en albei het steeds iemand nodig wat vir opdaterings en herstel verantwoordelik is.

Waarna ’n onion-adres werklik wys

’n v3 onion-adres kodeer die diens se openbare sleutel, en daarom kan niemand ’n adres kies vir ’n diens wat hy nie beheer nie. Die kliënt verbind deur Tor na ’n ontmoetingspunt, en die diens bereik dieselfde punt van sy kant af; geen gewone uitgangsknoop dra daardie verbinding na die diens nie. Die naam is ’n identiteit, nie ’n DNS-rekord nie.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Daarom help dit niks om ’n roete of ’n hosts-inskrywing vir ’n onion-naam by te voeg nie. Die opsoek is nie die meganisme nie; die Tor-kliënt en sy stroombane is. As die diens vir ’n klein groep mense bedoel is, kan onion-kliëntmagtiging ’n sleutel vereis voordat die verbinding aanvaar word, maar dit is steeds nie aanmelding by die toepassing nie. Om die adres te publiseer is ook ’n doelbewuste daad, want enigiemand wat dit leer ken, kan ’n verbinding probeer tensy jy dit beperk het.

Stop as die enigste rede vir die onion-ontwerp is om die opstel van verifikasie te vermy. Die oorlaag voorsien dit nie, en jy sal dit later tog bou.

Wat ’n VPN-roete werklik gee

’n VPN laat ’n toestel tot ’n netwerk toe en gee hom ’n roete na ’n poort of ’n subnet. Die diens agter daardie poort sien ’n adres uit die tonnelpoel en pas toe watter magtiging hy het. Die roete sê niks oor wie die gebruiker is nie; dit sê waar pakkette mag heen gaan.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Daardie model pas by ’n bekende groep met bestuurde toestelle, want die poort kan toestelpostuur afdwing en die netwerk kan geouditeer word. Dit pas swak by anonieme of ad hoc besoekers, wat eers ingeskryf sou moes word. Die toepassing se eie aanmelding is steeds die ding wat besluit wat ’n verbonde gebruiker mag lees. Om bereikbaarheid met toestemming te verwar, is hoe ’n VPN uiteindelik ’n hele subnet aan almal gee wat kan verbind.

Stop as die gehoor onbekend is of voortdurend verander. Om vreemdelinge in ’n privaat netwerk in te skryf om vir hulle een bladsy te wys, is ’n groot verbintenis vergeleke met die publikasie van ’n diens.

Kies tussen hulle, en wat dieselfde bly

Kies die onion-model wanneer die gehoor tegnies is, die diens glad geen openbare adres mag hê nie, en jy Tor se kliëntvereistes kan aanvaar. Kies die VPN-model wanneer die gehoor ’n bepaalde groep is wie se toestelle jy bestuur en wie se toegang jy op netwerkvlak wil log. Nie een keuse verwyder die behoefte aan verifikasie van die toepassing, pleisters of ’n herstelpad nie. Nie een is outomaties meer privaat in die sin wat vir jou gebruikers saak maak nie.

Skryf in albei ontwerpe neer wie die diens kan bereik, hoe hulle geïdentifiseer word en wat gebeur wanneer ’n geloofsbrief verlore gaan. Die antwoord vir ’n onion-diens sluit sy kliëntmagtiging-sleutels en die adres self in; die antwoord vir ’n VPN sluit die rekening, die toestel en die poortbeleid in. Dit is verskillende inventarisse, en net een daarvan sal vir die volgende administrateur vanselfsprekend wees.

Die vergelyking eindig waar die toepassing begin. ’n Verborge adres en ’n privaat roete is vervoerkeuses, en die toepassing moet steeds besluit wat ’n versoek mag doen. Hou daardie besluite in aparte dokumente, en geen van die twee ontwerpe sal stilweg die ander se werk oorneem nie.