Може ли една мрежа да блокира VPN, без да разбие криптирането?

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

Достижимостта е решение, което взема пътят

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

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

Стилове на намеса и цената на всеки

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

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

Черният списък е ограничен от това доколко добре адресът назовава услуга

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

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

Белият списък премества тежестта по поддръжка

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

Номерата на портовете са обичайното слабо място в такава дефиниция. Разрешаването на порт не е същото като идентифициране на всяко приложение, което може да го използва, затова белият списък, базиран на портове, често допуска повече, отколкото авторът му е възнамерявал. Пръстовите отпечатъци на протоколи имат същия проблем от друга страна, защото идентифицират формата на трафика, а не намерението. Затова белият списък не е автоматично по-точен от черния; той е точен относно друго нещо.

Какво може и какво не може да подкрепи едно наблюдение

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

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

curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.com

Забиване, което завършва с изтичане на времето, подсказва тихо изхвърляне; бързият отказ подсказва устройство, което отхвърля по пътя, а нулирането след свързване подсказва вмешателство със състояние, а не липсващ маршрут. Проучването на RFC 9505 за техниките на цензура описва контролните точки и моделите на намеса зад тези форми. Никое от тях обаче не казва колко широко се прилага политиката. Постоянството е по-силно твърдение от достижимостта: крайните точки, софтуерът, политиките и разрешените услуги всички се променят, така че неопределената ефективност изисква допускания за продължаващо прилагане, а не списък с адреси, видени в един момент.