На кого се доверявате, когато сами пускате VPN сървъра

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

Стъпка 1: опишете страните

Избройте всяка страна в реалното внедряване: вашето устройство, мрежата, към която се свързвате, VPN хоста, DNS резолвера и услугата дестинация. За всяка отбележете какво може да наблюдава и кои настройки контролирате вие.

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

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

Стъпка 2: запишете какво сте спечелили

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

Те са и условни. Неизползвана настройка по подразбиране и непроверено резервно копие не са свойства, които протоколът предоставя; това са намерения. Запишете контрола заедно с теста, който го доказва, иначе не се брои.

Стъпка 3: приемете списъка с поддръжка

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

Отзоваването заслужава свой ред. Устройство, което сте премахнали от конфигурацията, но никога не сте отзовали, все още има валидни идентификационни данни, а разликата се показва само когато някой ги използва. Тествайте премахването, като опитате да се свържете със стария материал.

Резервните копия се нуждаят от същото отношение. Възстановете една на резервен хост и потвърдете, че тунелът се вдига със същите идентичности. Резервно копие, което никога не сте възстановили, е файл, а не план за възстановяване.

Стъпка 4: изоставете предположението за анонимност

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

Има и по-фин ефект: адрес, използван само от вас, може да стане стабилен сигнал, свързан с използването ви. Търговският изход се споделя с непознати, което е лошо за поверителността по един начин и добро по друг. Вашият собствен адрес е уникален, което обръща тази размяна.

Ако целта е да сте трудни за корелиране, самостоятелният хостинг може да го направи по-скоро по-лесно, отколкото по-трудно. Решете какво свойство наистина искате, преди да отделите вечер за това. Уникалността е разход, а не характеристика, и не се появява в повечето текстове за самостоятелен хостинг. Запишете я в таблицата на страните от стъпка 1 и размяната става видима.

Стъпка 5: изберете го по посочена причина

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

След това проверете скучните части: хостът актуализиран ли е, старите ключове изчезнали ли са, съхранението съответства ли на документираното и можете ли да възстановите услугата след отказ? Тези четири отговора описват модела на доверие много по-добре от името на протокола.

Стъпка 6: планирайте изхода

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

Моделът моделът на споделена отговорност на AWS е полезен шаблон и извън AWS, защото налага същия въпрос: кой слой е ваш и кой принадлежи на някой друг. Отговорете за всяка страна от стъпка 1 и моделът на доверие престава да бъде лозунг.