Onion-szolgáltatás kontra VPN-szolgáltatás: eltérő hozzáférési modellek

Az emberek az Onion-szolgáltatást és a csak VPN-en át elérhető szolgáltatást ugyanazon ötlet két változataként írják le: rejtsd el a portot, oszd meg a titkos címet. Abban különböznek, mihez kötődik a cím, ki érheti el, és mi történik, mire egy kérés megérkezik. Az egyik találkozási pont a Toron belül, a másik útvonal egy magánhálózaton belül. Felcserélhetőként kezelésük olyan terveket eredményez, amelyek sem nem magánjellegűek, sem nem fenntarthatók.

A mítosz: mindkét terv csupán egy rejtett ajtó

A közös tulajdonság valós, de vékony: egyik terv sem teszi a felügyeleti felületet közvetlenül elérhető nyilvános portra. Minden más szétválik. Az Onion-cím a szolgáltatás saját kulcsából származik, ezért a név egy identitáshoz kötődik; a VPN-cím csupán egy cím egy hálózatban, amelybe beengedték. Az egyik egy burkolóhálózatba rejti a szolgáltatást, a másik egy magán-topológiába engedi be. A másodikat az első szinonimájának tekinteni ott a zavar kezdete.

Egyik tulajdonság sem biztonsági kontroll magának az alkalmazásnak. A rejtett hely nem javítja ki a mögötte lévő szoftvert, a magánútvonal pedig nem tesz hitelesítést a bejelentkező oldalra. Mindkét tervnek továbbra is szükősége van az alkalmazás saját jogosultságaira, és mindkettőnek továbbra is szükősége van valakire, aki a frissítésekért és a helyreállításért felel.

Mire mutat valójában egy Onion-cím

Az Onion-cím v3-as verziója a szolgáltatás nyilvános kulcsát kódolja, ezért senki sem választhat címet olyan szolgáltatásnak, amelyet nem irányít. A kliens a Toron keresztül kapcsolódik egy találkozási ponttól, és a szolgáltatás a saját oldaláról ugyanahhoz a ponttól érkezik; egyetlen közönséges kimeneti csomópont sem viszi ezt a kapcsolatot a szolgáltatáshoz. A név identitás, nem DNS-rekord.

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

Ezért haszontalan útvonalat vagy hosts-bejegyzést hozzáadni egy onion-névhez. A feloldás nem a mechanizmus; a Tor-kliens és a körei azok. Ha a szolgáltatás kis létszámú embercsoportnak szól, az onion kliens-hitelesítés kulcsot kérhet a kapcsolat elfogadása előtt, de ez még mindig nem alkalmazás-bejelentkezés. A cím közzététele is szándékos cselekvés, hiszen aki megtudja, kapcsolódást kísérelhet meg, hacsak nem korlátozta.

Álljon meg, ha az onion-terv egyetlen oka a hitelesítés beállításának elkerülése. A burkolóhálózat nem nyújtja ezt, és előbb-utóbb úgyis felépíti.

Mit ad valójában egy VPN-útvonal

A VPN beenged egy eszközt egy hálózatba, és útvonalat ad neki egy átjáróhoz vagy egy alhálózathoz. Az átjáró mögötti szolgáltatás címet lát az alagút készletéből, és alkalmazza a rendelkezésére álló jogosultságot. Az útvonal semmit sem mond arról, ki a felhasználó; azt mondja, hová mehetnek a csomagok.

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

Ez a modell jól illik felügyelt eszközökkel rendelkező ismert csoporthoz, mert az átjáró kikényszerítheti az eszköz állapotát, és a hálózat naplózható. Rosszul illik névtelen vagy alkalmi látogatókhoz, akiket előbb fel kellene venni. Az alkalmazás saját bejelentkezése dönt továbbra is arról, mit olvashat egy csatlakozott felhasználó. Az elérhetőség és a jogosultság összekeverése vezet oda, hogy a VPN végül egy egész alhálózatot ad mindenkinek, aki kapcsolódhat.

Álljon meg, ha a közönség ismeretlen, vagy folyamatosan változik. Idegeneket felvenni egy magánhálózatba egyetlen oldal megmutatásáért nagy kötelezettségvállalás egy szolgáltatás közzétételéhez képest.

Választás a kettő között, és mi marad ugyanaz

Az onion-modellt válassza, ha a közönség technikai, a szolgáltatásnak egyáltalán nem lehet nyilvános címe, és el tudja fogadni a Tor klienskövetelményeit. A VPN-modellt válassza, ha a közönség meghatározott csoport, amelynek eszközeit Ön felügyeli, és amelynek hozzáférését hálózati szinten szeretné naplózni. Egyik választás sem szünteti meg az alkalmazás hitelesítésének, a javításoknak vagy a helyreállítási útnak a szükőségét. Egyik sem magánjellegűbb automatikusan abban az értelemben, amely az Ön felhasználói számára számít.

Mindkét tervben írja le, ki érheti el a szolgáltatást, hogyan azonosítják őket, és mi történik, ha egy hitelesítő adat elveszik. Az onion-szolgáltatás válasza magában foglalja a kliens-hitelesítési kulcsokat és magát a címet; a VPN válasza magában foglalja a fiókot, az eszközt és az átjáró házirendjét. Ezek különböző leltárak, és csak az egyik lesz nyilvánvaló a következő rendszergazdának.

Az összehasonlítás ott ér véget, ahol az alkalmazás elkezdődik. A rejtett cím és a magánútvonal szállítási választás, és az alkalmazásnak továbbra is el kell döntenie, mit tehet egy kérés. Tartsa ezeket a döntéseket külön dokumentumokban, és egyik terv sem veszi át csendben a másik munkáját.