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

Започнете от клиента, не от сървъра

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

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

Първа стъпка: потвърдете блокирането по пътищата, за които смятате, че го покрива

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

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Искате клиент, който се проваля бързо и чисто, а не такъв, който виси до изтичане на времето на браузъра. Зависването обикновено означава, че пакетите се изхвърлят тихо от правило без отказ, което е приемливо, но може да означава и че клиентът е оставил остарял маршрут по подразбиране, насочен към мъртъв интерфейс. Прочетете таблицата за маршрутизиране, докато тунелът е изключен: маршрут по подразбиране, който още сочи към устройството на тунела, и правило на защитната стена, което блокира само нови изходящи връзки, са две различни състояния и само едно от тях е fail-closed.

Повторете същите команди с включена и изключена опция allow-LAN на клиента. Този превключвател е мястото на повечето изненади, защото отваря отново път, който останалата част от политиката е писана да затвори.

Втора стъпка: проверете DNS и IPv6 като отделни пътища

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Празни отговори и за двете заявки за имена при изключен тунел са резултатът, който искате. Ако втората заявка отговори, твърдо зададен адрес на резолвер е достъпен и тунелът не е единственият път от машината. Ако само заявката v6 успее, политиката покрива IPv4 и игнорира IPv6, което е същата теч в друго семейство адреси.

Браузърите правят това по-трудно за четене отвън, защото браузър, настроен за DNS over HTTPS, разрешава заявката чрез HTTPS заявка: заявката е блокирана само доколкото е блокиран порт 443 към тази крайна точка. На хост, където политиката позволява локалната подмрежа, тази заявка все още може да достигне резолвер в LAN.

Трета стъпка: отделете мрежовата експозиция от експозицията на крайните точки

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

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

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

Четвърта стъпка: формулирайте твърдението, което тестът ви подкрепя

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

Дръжте двата проблема отделно и дайте на всеки собствен контрол:

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

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

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