Onion-tjänst kontra VPN-tjänst: olika åtkomstmodeller

Folk beskriver en Onion-tjänst och en tjänst som bara nås via VPN som två varianter av samma idé: göm porten, dela den hemliga adressen. De skiljer sig i vad adressen är knuten till, vem som kan nå den och vad som måste hända innan en begäran kommer fram. Den ena är en mötesplats inuti Tor, den andra är en väg inuti ett privat nätverk. Att behandla dem som utbytbara ger design som varken är privat eller underhållbar.

Myten: båda designerna är bara en dold dörr

Den gemensamma egenskapen är verklig men tunn: ingen av designerna sätter administrationsgränssnittet på en direkt nåbar publik port. Allt därefter går isär. En Onion-adress härleds från tjänstens egen nyckel, så namnet är knutet till en identitet; en VPN-adress är bara en adress i ett nätverk du släppts in i. Den ena gömmer tjänsten i ett överlägg, den andra släpper in dig i en privat topologi. Just att se den andra som en synonym till den första är där förvirringen börjar.

Ingen av egenskaperna är en säkerhetskontroll för själva applikationen. En dold plats lappar inte programvaran bakom den, och en privat väg lägger inte till autentisering på inloggningssidan. Båda designerna behöver fortfarande applikationens egna behörigheter, och båda behöver fortfarande någon som ansvarar för uppdateringar och återställning.

Vad en Onion-adress faktiskt pekar på

En Onion-adress i version v3 kodar tjänstens publika nyckel, och därför kan ingen välja en adress till en tjänst de inte kontrollerar. Klienten ansluter via Tor till en mötesplats, och tjänsten når samma punkt från sin sida; ingen vanlig utgångsnod bär den förbindelsen till tjänsten. Namnet är en identitet, inte en DNS-post.

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

Därför hjälper det inte att lägga till en väg eller en hosts-post för ett onion-namn. Uppsökningen är inte mekanismen; Tor-klienten och dess kretsar är det. Om tjänsten är avsedd för en liten grupp människor kan onion-klientauktorisation kräva en nyckel innan anslutningen accepteras, men det är fortfarande inte inloggning i applikationen. Att publicera adressen är också en medveten handling, eftersom alla som lär sig den kan försöka ansluta om du inte har begränsat den.

Stanna om det enda skälet till onion-designen är att undvika att ställa in autentisering. Överlägget ger inte det, och du bygger det ändå senare.

Vad en VPN-väg faktiskt ger

En VPN släpper in en enhet i ett nätverk och ger den en väg till en gateway eller ett subnät. Tjänsten bakom den gatewayen ser en adress från tunnelpoolen och tillämpar den auktorisation den har. Vägen säger ingenting om vem användaren är; den säger vart paketen får gå.

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

Den modellen passar en känd grupp med hanterade enheter, eftersom gatewayen kan genomdriva enhetens tillstånd och nätverket kan granskas. Den passar dåligt för anonyma eller tillfälliga besökare, som först skulle behöva registreras. Applikationens egen inloggning avgör fortfarande vad en ansluten användare får läsa. Att blanda ihop nåbarhet med behörighet är hur en VPN till slut ger ett helt subnät till alla som kan ansluta.

Stanna om publiken är okänd eller förändras ständigt. Att registrera främlingar i ett privat nätverk för att visa dem en sida är ett stort åtagande jämfört med att publicera en tjänst.

Att välja mellan dem, och vad som förblir detsamma

Välj onion-modellen när publiken är teknisk, tjänsten inte får ha någon publik adress alls och du kan acceptera Tor-klientens krav. Välj VPN-modellen när publiken är en definierad grupp vars enheter du hanterar och vars åtkomst du vill logga på nätverksnivå. Ingen av valen tar bort behovet av appautentisering, patchning eller en återställningsväg. Ingen av dem är automatiskt mer privat i den mening som betyder något för dina användare.

Skriv i båda designerna ned vem som kan nå tjänsten, hur de identifieras och vad som händer när en inloggningsuppgift går förlorad. Svaret för en Onion-tjänst omfattar dess klientauktorisationsnycklar och själva adressen; svaret för en VPN omfattar kontot, enheten och gateway-policyn. Dessa är olika förteckningar, och bara en av dem kommer att vara självklar för nästa administratör.

Jämförelsen slutar där applikationen börjar. En dold adress och en privat väg är transportval, och applikationen måste fortfarande avgöra vad en begäran får göra. Håll dessa beslut i separata dokument, och ingen av designerna kommer att tyst överta den andras arbete.