Как да ограничим достъпа между два офиса, свързани чрез VPN

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

Работете в този ред и не разширявайте маршрута на тунела, докато стъпките на политиката по-долу не минат.

Напишете матрицата, преди да пипате шлюза

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

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

Налагайте там, където пакетите се дешифрират

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

Селекторите на трафик са решение за маршрутизиране, а не за оторизация. Широк селектор, който покрива двете подмрежи, може да е правилен за маршрутизирането, докато защитната стена все още разрешава само TCP 443 към един хост. Селекторът се договаря за тунела и описва какво може да влезе в него, а не какво може да използва дадено устройство. Никога не разширявайте правило на защитната стена, защото селекторът е широк.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT и припокриващите се подмрежи променят правилата

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

Припокриващите се диапазони са другата капана. Два офиса, които и двата използват 192.168.1.0/24, не могат да бъдат описани в една таблица на политиката без преобразуване на една страна, а преобразуването не заменя адресиране, което не се сблъсква. Оправете плана, преди да пишете правила, които ще трябва да разплитате по-късно.

Докажете отказ, а не само успех

Тестването само на разрешеното приложение доказва много малко, защото разрешаващо правило някъде по-нагоре дава същия резултат.

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

Пазете списъка жив

Приложенията се местят и правило, което надживее приложението си, се превръща в дупка, която никой не притежава. Прикрепете датата за преглед към реда и променете обхвата на селектора и правилото на защитната стена в една и съща стъпка по поддръжка, когато услуга смени адреса си.

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