Защо споделен TAP VPN все още се нуждае от HTTPS на портала

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

Какво всъщност удостоверява VPN

VPN ръкостискането отговаря на един въпрос: кой партньор е завършил този тунел и с какъв ключов материал. Този отговор е за всеки партньор и всяка връзка и не казва нищо за услугите, които партньорът показва след това. В TAP сегмент партньорът дори не е един адрес, защото може да представи всеки MAC и всеки IP, който мостът е готов да научи. Удостоверяването спира в края на тунела, а не в приложението.

Разделете трите въпроса, вместо да ги сливате в един. Всеки има свой механизъм и свой начин на отказ.

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

ARP в споделен сегмент не е указател

ARP съпоставя IPv4 адрес с MAC на локалната връзка и приема отговори от всеки в тази връзка. В разрешителен мостов сегмент партньор може да заяви адрес, който принадлежи на друго устройство, и мостът препраща кадри към този, който е отговорил последен. Шифроването на всеки клиентски път до сървъра не променя това, защото кадрите се дешифрират, преди да стигнат до моста. Границата на доверие на ARP е сегментът, а не тунелът.

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

Изолацията на партньорите и политиката на моста съществуват точно за този случай. Маршрутизираният дизайн обикновено е по-добрият отговор, когато услугата е само IP и устройствата нямат никаква причина да виждат кадрите си взаимно.

Пазете проверката на сертификата там, където е услугата

TLS на приложението отговаря на въпроса, на който тунелът не може: това ли е услугата, която исках да достигна. Браузърът проверява името на хоста спрямо сертификата и тази проверка е единствената част от веригата, която назовава портала, а не партньора.

Прегледайте какво представя сървърът, преди да решите, че предупреждението е козметично. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal отпечатва веригата и алтернативните имена на субекта. Ако въведеното от вас име липсва в този списък, предупреждението е правилно и сертификатът е това, което трябва да се поправи. Да учите потребителите да го подминават превръща работеща контрола в украшение.

Ръководството за мостове на OpenVPN описва модела Ethernet и опциите за политика около него и е правилната справка за това какво се предполага да позволява сегментът. Прочетете го, преди да разхлабите правило на моста, защото описаният там модел е това, което предполага всяка проверка по-горе.

Решете дали тези партньори въобще трябва да споделят сегмент

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

Ако сегментът трябва да остане, проверете настройката от страна на сървъра, която позволява на клиентите да се достигат: grep -n client-to-client /etc/openvpn/server.conf. Когато е изключена, клиентският трафик минава през сървъра и може да се филтрира там. Когато е включена, партньорите разменят кадри директно през моста и вашите точки за филтриране са мостът и защитната стена на хоста.

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