Потребител на MikroTik VPN стига твърде далеч: ограничете до един хост и един порт

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

Удостоверяването свършва там, където започва разрешението

Щом PPP сесията е вдигната, пакетите от клиента влизат във веригата forward като трафик от всеки друг интерфейс. Ако forward политиката на рутера е разрешителна, консултантът наследява тази разрешителност при входа. Акаунтът никога не е носил обхват, така че няма какво да се промени в него. Наборът от правила е писан за служители и новата сесия просто се присъедини към него.

Проверете кой път засяга заявката, преди да напишете нещо. Трафикът към хостовете зад рутера преминава през forward, докато трафикът към самия рутер, включително winbox и SSH, преминава през input. Обхват, който покрива само forward, оставя устройството отворено за същия клиент.

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

Прикачете сесията към именуван списък

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

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

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

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Запишете разрешената услуга в един списък

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

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

Ограничете протокола и порта, както и хоста. Accept за хост без ограничение на порта отваря всяка услуга, която този хост изпълнява, което е по-широко, отколкото повечето заявки за достъп предполагат. Портът е част от разрешението, а не подробност, която се добавя по-късно.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Подредете прескачането преди всеки широк accept

Правило за прескачане изпраща препратения трафик от ограничения списък в частна верига, където цялата политика се побира в три реда. Първото правило приема разрешената дестинация и порт, а последното отхвърля всичко останало. Прескачането трябва да стои над всеки широк accept във forward, защото по-ранен accept означава, че прескачането никога не се изпълнява. Дръжте accept за established и related преди прескачането, за да продължи да тече обратният трафик.

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

Повторете решението за веригата input, ако собствените услуги на рутера трябва да са недостъпни. Обхват, който блокира препратения трафик и оставя winbox отворен, е само наполовина завършен.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Проверете с броячи и членство в списъка

От клиента тествайте разрешената услуга и такава, която трябва да се провали, после прочетете статистиката на правилата на рутера. Броячите за accept и drop показват по кой път е минал всеки пакет, което клиентът не може да види. Потвърдете също, че адресът на активната сесия се е появил в ограничения списък.

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

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

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients