Како ограничити приступ између две канцеларије повезане VPN-ом

Тунел између локација одговара на једно питање, могу ли две канцеларије размењивати пакете, а важно оставља отворено: који уређај огранка сме да достигне коју централну услугу. Третирање тунела као узајамног поверења је пут којим гостујући лаптоп завршава на истој рути као финансијски сервер. Решење није бољи тунел, већ јасан списак дозвола који се примењује после дешифровања. Овај приручник води тај списак од дефиниције до доказаног одбијања.

Радите овим редоследом и не ширите руту тунела док кораци политике испод не прођу.

Напишите матрицу пре него што дотакнете пролаз

Користан ред именује три ствари: групу извора, одредишни хост или сервисну мрежу, и протокол и порт које апликација заиста користи. Огранак и центар података нису ставке. Приватни DNS и услуге аутентификације заслужују своје редове само када апликација не може да ради без њих.

Групишите изворе по улози, а не по погодности подмреже: запослени, гости, администрација. Када сва три деле једну равну LAN, пролаз их не може разликовати на мрежном нивоу, па контрола идентитета или сегментација морају доћи прве. Затим ставите матрицу писмено, са власником и датумом прегледа у сваком реду.

Примените то тамо где се пакети дешифрују

Правила која дозвољавају IKE и ESP граде само спољашњи тунел. Унутрашњи саобраћај стиже отворено на интерфејс тунела, и управо ту је место списка дозвола: ланац прослеђивања на уређају који дешифрује, подразумевано одбацивање, једно правило за сваки ред матрице. На Linux пролазима то значи омогућено прослеђивање и филтер правила на уређају тунела, а не на физичкој вези, као што објашњава водич strongSwan-а за прослеђивање.

Селектори саобраћаја су одлука о рутирању, а не о ауторизацији. Широк селектор који покрива обе подмреже може бити тачан за рутирање, док firewall и даље дозвољава само TCP 443 ка једном хосту. Селектор се договара за тунел и описује шта сме ући у њега, а не шта сме користити дати уређај. Никада не шири правило firewall-а зато што је селектор широк.

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 не могу се описати у једној таблици политике без мапирања једне стране, а мапирање није замена за адресирање које се не судара. Поправите план пре него што напишете правила која ћете касније морати да одмотавате.

Докажите одбијање, не само успех

Тестирање само дозвољене апликације доказује веома мало, јер попустљиво правило негде изнад даје исти резултат.

Са обичног уређаја у огранку достигните предвиђену услугу и потврдите да цела сесија ради. Затим покушајте одредиште које мора остати затворено, као административни порт на серверу са којим огранак нема никаква посла, и прочитајте бројач или запис у дневнику који га је одбацио. Искључивање скупа правила да проверите да ли ради чини тест неважећим и оставља пролаз отворен док гледате.

Држите списак живим

Апликације се премештају, а правило које надживи своју апликацију постаје рупа коју нико не поседује. Прикачите датум прегледа на ред и промените опсег селектора и правило firewall-а у истом кораку одржавања када услуга промени адресу.

Ограничења на нивоу хоста су и даље важна иза тунела: сопствени firewall сервера треба да прихвата опсег огранка само за услугу коју објављује. Два слоја која се слажу лакше је ревидирати од једног слоја коме се потпуно верује.