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

Две политики, един тунел

Външната политика отговаря на прост въпрос: може ли пакет от този източник да достигне UDP 1194 на този хост? Вътрешната политика отговаря на друг: може ли удостовереният клиент зад този тунел да достигне тази дестинация, по този протокол, на този порт? Първото е за сокет, второто е за път, и firewalld ги моделира с различни обекти, защото се решават в различни точки. Едното е свойство на сокет на този хост, другото — на път през него.

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

Допуснете действителния външен слушател

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

Оторизирайте дешифрираната дестинация отделно

Връзка към услуга, работеща на самия VPN сървър, е политика за локален вход. Връзка, препращана към друг хост в LAN, изисква политика за препращане, препращане, включено в ядрото, и обратен маршрут — това са три отделни изисквания, които хората често свиват в едно. Съвременните обекти на политики във firewalld описват насочен трафик между входяща зона и изходяща зона и това е правилното място да се изрази кои VPN източници могат да достигнат кои частни услуги.

Дефинирайте разрешените източници изрично и оставете всичко останало да падне в отказ. Допуск за външната услуга не е тази политика, колкото и да изглежда подредбата на зоните.

Защо доверието към интерфейса е грешният пряк път

Поставянето на интерфейса на тунела в зона, чиято цел приема всичко, допуска целия дешифриран трафик до всяка услуга, която хостът излага, включително такива, които не сте прегледали. Пренасочването на доверената зона към ограничаваща на работеща машина е по-лошо, защото други интерфейси и диапазони от източници може вече да зависят от значението ѝ и ще променят поведение, когато я редактирате. Ако ви трябва тясна политика, създайте такава; не преизползвайте споделена зона.

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

Проверете три неща, включително един отказ

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

Запишете зоната, порта, транспорта и обекта на политика в бележките на сървъра. Иначе следващата промяна на този хост ще започне от същото предположение.

Подобни статии