Onion-tjeneste kontra VPN-tjeneste: forskjellige tilgangsmodeller

Folk beskriver en Onion-tjeneste og en tjeneste som bare nås via VPN som to varianter av samme idé: skjul porten, del den hemmelige adressen. De skiller seg i hva adressen er bundet til, hvem som kan nå den, og hva som må skje før en forespørsel kommer. Den ene er et møtested inne i Tor, den andre er en rute inne i et privat nettverk. Å behandle dem som utskiftbare gir design som verken er private eller vedlikeholdbare.

Myten: begge designene er bare en skjult dør

Den felles egenskapen er reell, men tynn: ingen av designene setter administrasjonsgrensesnittet på en direkte tilgjengelig offentlig port. Alt etterpå divergerer. En Onion-adresse utledes fra tjenestens egen nøkkel, så navnet er bundet til en identitet; en VPN-adresse er bare en adresse i et nettverk du er sluppet inn i. Det ene skjuler tjenesten i et overlag, det andre slipper deg inn i en privat topologi. Å se det andre som et synonym for det første er der forvirringen begynner.

Ingen av egenskapene er en sikkerhetskontroll for selve applikasjonen. Et skjult sted lapper ikke programvaren bak det, og en privat rute legger ikke til autentisering på innloggingssiden. Begge designene trenger fortsatt applikasjonens egne tillatelser, og begge trenger fortsatt noen som er ansvarlig for oppdateringer og gjenoppretting.

Hva en Onion-adresse faktisk peker på

En Onion-adresse i versjon v3 koder tjenestens offentlige nøkkel, og derfor kan ingen velge en adresse til en tjeneste de ikke kontrollerer. Klienten kobler seg gjennom Tor til et møtested, og tjenesten når samme punkt fra sin side; ingen vanlig utgangsnode bærer den forbindelsen til tjenesten. Navnet er en identitet, ikke en DNS-oppføring.

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

Derfor hjelper det ikke å legge til en rute eller en hosts-oppføring for et onion-navn. Oppslaget er ikke mekanismen; Tor-klienten og kretsene dens er det. Hvis tjenesten er ment for en liten gruppe mennesker, kan onion-klientautorisasjon kreve en nøkkel før forbindelsen godtas, men det er fortsatt ikke applikasjonsinnlogging. Å publisere adressen er også en bevisst handling, siden alle som lærer den kan forsøke en forbindelse med mindre du har begrenset den.

Stopp hvis den eneste grunnen til onion-designet er å unngå å sette opp autentisering. Overlaget gir ikke det, og du bygger det uansett senere.

Hva en VPN-rute faktisk gir

En VPN slipper en enhet inn i et nettverk og gir den en rute til en gateway eller et subnett. Tjenesten bak den gatewayen ser en adresse fra tunnelpoolen og bruker den autorisasjonen den har. Ruten sier ingenting om hvem brukeren er; den sier hvor pakkene kan gå.

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

Den modellen passer for en kjent gruppe med administrerte enheter, fordi gatewayen kan håndheve enhetens tilstand og nettverket kan revideres. Den passer dårlig for anonyme eller tilfeldige besøkende, som først måtte registreres. Applikasjonens egen innlogging avgjør fortsatt hva en tilkoblet bruker kan lese. Å forveksle tilgjengelighet med tillatelse er hvordan en VPN ender med å gi et helt subnett til alle som kan koble til.

Stopp hvis publikum er ukjent eller endrer seg stadig. Å registrere fremmede i et privat nettverk for å vise dem én side er en stor forpliktelse sammenlignet med å publisere en tjeneste.

Å velge mellom dem, og hva som forblir det samme

Velg onion-modellen når publikum er teknisk, tjenesten ikke må ha noen offentlig adresse i det hele tatt, og du kan godta Tors klientkrav. Velg VPN-modellen når publikum er en definert gruppe hvis enheter du administrerer og hvis tilgang du vil logge på nettverkslaget. Ingen av valgene fjerner behovet for applikasjonsautentisering, lapping eller en gjenopprettingsvei. Ingen av dem er automatisk mer privat i den forstanden som betyr noe for brukerne dine.

Skriv i begge designene ned hvem som kan nå tjenesten, hvordan de identifiseres, og hva som skjer når en påloggingsopplysning går tapt. Svaret for en Onion-tjeneste omfatter dens klientautorisasjonsnøkler og selve adressen; svaret for en VPN omfatter kontoen, enheten og gateway-policyen. Dette er forskjellige fortegnelser, og bare én av dem vil være åpenbar for den neste administratoren.

Sammenligningen slutter der applikasjonen begynner. En skjult adresse og en privat rute er transportvalg, og applikasjonen må fortsatt avgjøre hva en forespørsel får gjøre. Hold disse beslutningene i separate dokumenter, og ingen av designene vil stille overta den andres arbeid.