Onion-tjeneste kontra VPN-tjeneste: forskellige adgangsmodeller

Folk beskriver en Onion-tjeneste og en tjeneste, der kun nås via VPN, som to varianter af den samme idé: skjul porten, del den hemmelige adresse. De adskiller sig i, hvad adressen er bundet til, hvem der kan nå den, og hvad der skal ske, før en anmodning ankommer. Den ene er et mødested inde i Tor; den anden er en rute inde i et privat netværk. At behandle dem som udskiftelige giver design, der hverken er private eller vedligeholdbare.

Myten: begge design er bare en skjult dør

Den fælles egenskab er reel, men tynd: ingen af designene sætter den administrative grænseflade på en direkte tilgængelig offentlig port. Alt derefter divergerer. En Onion-adresse udledes af tjenestens egen nøgle, så navnet er bundet til en identitet; en VPN-adresse er blot en adresse i et netværk, du er blevet lukket ind i. Det ene skjuler tjenesten i et overlay, det andet lukker dig ind i en privat topologi. At se det andet som et synonym for det første er, hvor forvirringen begynder.

Ingen af egenskaberne er en sikkerhedskontrol for selve applikationen. En skjult placering lapper ikke softwaren bag den, og en privat rute tilføjer ikke godkendelse til login-siden. Begge design har stadig brug for applikationens egne tilladelser, og begge har stadig brug for nogen, der er ansvarlig for opdateringer og gendannelse.

Hvad en Onion-adresse egentlig peger på

En Onion-adresse i version v3 koder tjenestens offentlige nøgle, og derfor kan ingen vælge en adresse til en tjeneste, de ikke kontrollerer. Klienten forbinder gennem Tor til et mødested, og tjenesten når samme punkt fra sin side; ingen almindelig udgangsnode bærer den forbindelse til tjenesten. Navnet er en identitet, ikke en DNS-post.

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

Derfor hjælper det ikke at tilføje en rute eller en hosts-post for et onion-navn. Opslaget er ikke mekanismen; Tor-klienten og dens kredse er. Hvis tjenesten er beregnet til en lille gruppe mennesker, kan onion-klientgodkendelse kræve en nøgle, før forbindelsen accepteres, men det er stadig ikke applikationslogin. At offentliggøre adressen er også en bevidst handling, da enhver, der lærer den, kan forsøge en forbindelse, medmindre du har begrænset den.

Stop, hvis den eneste grund til onion-designet er at undgå at konfigurere godkendelse. Overlayet giver ikke det, og du bygger det alligevel senere.

Hvad en VPN-rute egentlig giver

En VPN lukker en enhed ind i et netværk og giver den en rute til en gateway eller et subnet. Tjenesten bag den gateway ser en adresse fra tunnelpuljen og anvender den autorisation, den har. Ruten siger intet om, hvem brugeren er; den siger, hvor pakker må gå hen.

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

Den model passer til en kendt gruppe med administrerede enheder, fordi gatewayen kan håndhæve enhedens tilstand, og netværket kan revideres. Den passer dårligt til anonyme eller ad hoc-besøgende, som først skulle indskrives. Applikationens eget login er stadig det, der afgør, hvad en tilsluttet bruger må læse. At forveksle tilgængelighed med tilladelse er, hvordan en VPN ender med at give et helt subnet til alle, der kan forbinde.

Stop, hvis publikum er ukendt eller skifter konstant. At indskrive fremmede i et privat netværk for at vise dem én side er en stor forpligtelse sammenlignet med at offentliggøre en tjeneste.

At vælge mellem dem, og hvad der forbliver det samme

Vælg onion-modellen, når publikum er teknisk, tjenesten slet ikke må have en offentlig adresse, og du kan acceptere Tors klientkrav. Vælg VPN-modellen, når publikum er en defineret gruppe, hvis enheder du administrerer, og hvis adgang du vil logge på netværkslaget. Ingen af valgene fjerner behovet for applikationsgodkendelse, patching eller en gendannelsesvej. Ingen af dem er automatisk mere privat i den forstand, der betyder noget for dine brugere.

Skriv i begge design ned, hvem der kan nå tjenesten, hvordan de identificeres, og hvad der sker, når en legitimationsoplysning mistes. Svaret for en onion-tjeneste omfatter dens klientautorisationsnøgler og selve adressen; svaret for en VPN omfatter kontoen, enheden og gatewaypolitikken. Det er forskellige fortegnelser, og kun én af dem vil være indlysende for den næste administrator.

Sammenligningen slutter, hvor applikationen begynder. En skjult adresse og en privat rute er transportvalg, og applikationen skal stadig afgøre, hvad en anmodning må gøre. Hold disse beslutninger i separate dokumenter, og ingen af designene vil stille overtaget den andens arbejde.