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

Сървърът вижда един адрес на връзка

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

Всичко след този адрес на източника е данни на приложението и приложението може да им вярва само доколкото ги удостоверява.

Проверете как изглежда вашият изход

Погледнете пътя от двата края, преди да пишете правило. Гледната точка на клиента за неговия изход и гледната точка на сървъра за връзката са двата факта, които имат значение.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

Може да бъде изброен само един от двата набора изходи

Единият случай е проверим в момента на заявката, а другият не, което дава много различни гаранции.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

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

Използвайте адресите като вход за политика, а не като доказателство

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

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

Подобни статии