Користувач 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