Onion услуга срещу VPN услуга: различни модели за достъп

Хората описват Onion услуга и услуга, достъпна само през VPN, като два варианта на една и съща идея: скрий порта, сподели тайния адрес. Те се различават по това към какво е обвързан адресът, кой може да го достигне и какво трябва да се случи, преди да пристигне заявка. Едното е място за среща вътре в Tor, другото е маршрут в частна мрежа. Да ги третираме като взаимозаменяеми поражда решения, които не са нито частни, нито поддържаеми.

Митът: и двата модела са просто скрита врата

Общото свойство е реално, но крехко: нито един от моделите не поставя административния интерфейс на пряко достъпен публичен порт. Всичко след това се разминава. Onion адресът се извлича от собствения ключ на услугата, затова името е обвързано с идентичност; VPN адресът е просто адрес в мрежа, в която сте допуснати. Едното скрива услугата в наслагваща мрежа, другото ви допуска в частна топология. Третирането на второто като синоним на първото е началото на объркването.

Нито едно от свойствата не е средство за сигурност на самото приложение. Скритото място не кърпи софтуера зад него, а частният маршрут не добавя удостоверяване към страницата за вход. И двата модела все още се нуждаят от собствените разрешения на приложението и от някой, отговорен за обновяванията и възстановяването.

Към какво всъщност сочи Onion адресът

Адрес Onion версия v3 кодира публичния ключ на услугата, поради което никой не може да избере адрес за услуга, която не контролира. Клиентът се свързва през Tor с място за среща, а услугата достига същата точка от своята страна; нито един обикновен изходен възел не носи тази връзка до услугата. Името е идентичност, а не DNS запис.

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

Затова добавянето на маршрут или запис в hosts за onion име не помага с нищо. Търсенето не е механизмът; механизът е Tor клиентът и неговите вериги. Ако услугата е предназначена за малка група хора, onion оторизацията на клиента може да изисква ключ, преди връзката да бъде приета, но това все още не е вход в приложението. Публикуването на адреса също е умишлено действие, тъй като всеки, който го научи, може да опита връзка, освен ако не сте го ограничили.

Спрете, ако единствената причина за модела onion е да избегнете настройването на удостоверяване. Наслагващата мрежа не го осигурява и вие ще го изградите по-късно така или иначе.

Какво всъщност дава VPN маршрутът

VPN допуска устройство в мрежа и му дава маршрут до шлюз или подмрежа. Услугата зад този шлюз вижда адрес от пула на тунела и прилага това, за което има оторизация. Маршрутът не казва нищо за това кой е потребителят; той казва накъде могат да отиват пакетите.

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

Този модел подхожда на известна група с управлявани устройства, защото шлюзът може да наложи изисквания за състоянието на устройството, а мрежата може да се одитира. Той е лош за анонимни или случайни посетители, които първо трябва да бъдат записани. Входът на самото приложение все още решава какво може да чете свързан потребител. Объркването на достъпност с разрешение е начинът, по който VPN в крайна сметка дава цяла подмрежа на всеки, който може да се свърже.

Спрете, ако аудиторията е неизвестна или се променя постоянно. Записването на непознати в частна мрежа, за да им покажете една страница, е голям ангажимент в сравнение с публикуването на услуга.

Избор между тях и какво остава същото

Изберете модела onion, когато аудиторията е техническа, услугата изобщо не трябва да има публичен адрес и можете да приемете изискванията на Tor клиента. Изберете модела VPN, когато аудиторията е определена група, чиито устройства управлявате и чийто достъп искате да отчитате на мрежово ниво. Нито един избор не премахва нуждата от удостоверяване на приложението, кърпене или път за възстановяване. Нито един не е автоматично по-поверителен в смисъла, който е важен за потребителите ви.

И в двата модела запишете кой може да достигне услугата, как се идентифицират и какво се случва при загуба на идентификационни данни. Отговорът за onion услуга включва нейните ключове за клиентска оторизация и самия адрес; отговорът за VPN включва акаунта, устройството и политиката на шлюза. Това са различни описи и само един от тях ще е очевиден за следващия администратор.

Сравнението свършва там, където започва приложението. Скритият адрес и частният маршрут са избор на транспорт и приложението все още трябва да реши какво му е позволено на една заявка. Пазете тези решения в отделни документи и нито един модел няма тихо да поеме работата на другия.