Зашто заједнички TAP VPN и даље захтева HTTPS на порталу
TAP VPN аутентификује партнера, а не услугу иза њега. Задржите проверу имена домаћина на порталу и изолујте суседе којима не верујете.
Два уређаја имају важеће VPN податке за приступ и деле један мостни Ethernet сегмент. Само један од њих треба да одговара за канцеларијски портал, а други и даље може да присвоји адресу портала на том сегменту. Тунел је обавио свој посао: аутентификовао је оба партнера и шифровао сваку путању до сервера. Оно што није учинио јесте да потврди који од њих поседује име услуге, и управо тај јаз је разлог зашто порталу и даље треба важећи сертификат.
Шта VPN заправо аутентификује
VPN руковање одговара на једно питање: који је партнер завршио овај тунел и са којим кључним материјалом. Тај одговор важи по партнеру и по вези и не говори ништа о услугама које тај партнер затим излаже. На TAP сегменту партнер није чак ни једна адреса, јер може представити било који MAC и било који IP који је мост спреман да научи. Аутентификација се зауставља на крају тунела, а не у апликацији.
Раздвојите три питања уместо да их спајате у једно. Свако има свој механизам и свој начин отказа.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Распоређивање може имати савршено аутентификован тунел и потпуно неаутентификовану услугу иза њега. Може имати и валидиран сертификат на домаћину чију адресу другог слоја присваја други партнер, и зато обе контроле припадају пројекту, а не једна уместо друге. Табела је цео аргумент у три реда.
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 апликације. Домаћин који се ослања на све три је у реду. Домаћин који се ослања на прву и претпоставља да су друге две дошле с њом је онај који на крају служи погрешан садржај.