Зоны Shorewall для двух путей пакетов OpenVPN
Отделите зашифрованный транспорт OpenVPN от расшифрованного клиентского трафика, выделите туннелю собственную зону и разрешите только ту единственную службу, которая нужна клиенту.
Два потока пакетов проходят через шлюз Shorewall, который завершает OpenVPN, и только один из них зашифрован. Первый — транспорт клиента к слушателю VPN на интерфейсе, обращённом в интернет. Второй — расшифрованный запрос, покидающий интерфейс туннеля, к офисному серверу или службе на шлюзе. Отобразите оба потока до правки политики, потому что правило, которое удовлетворяет первому, ничего не делает для второго.
Нарисуйте оба потока до правки политики
Запишите потоки строками с источником, назначением, протоколом и портом. На внешнем пути источник — публичный адрес клиента, а назначение — порт прослушивания шлюза; Shorewall рассматривает это как трафик из интернета к межсетевому экрану. На внутреннем пути источник — диапазон адресов туннеля, а назначение — одобренная служба. У двух строк разные владельцы, даже когда один администратор сопровождает обе.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Добавляйте строку только тогда, когда запрос заканчивается на самом шлюзе, например доступ к резолверу или к управлению. Служба на хосте подчиняется политике входящего трафика хоста, а не пересылаемому пути. Именно смешение этих двух и приводит к тому, что узкое правило туннеля в итоге открывает административный интерфейс.
Назначьте зону туннеля и охват интерфейса
Зона путешественника объявляется в /etc/shorewall/zones, интерфейс туннеля подключается в /etc/shorewall/interfaces, а внешнее соединение описывается в /etc/shorewall/tunnels. Согласуйте синтаксис с установленным выпуском, потому что порядок столбцов и имена параметров менялись между основными версиями. Пример порта из руководства не повод разрешать порт, отличный от того, на котором демон действительно слушает. TCP и UDP не взаимозаменяемы только потому, что числа совпадают.
Руководство группирует интерфейсы через tun+. На хосте с несколькими туннелями этот шаблон может поместить вторую VPN с другим уровнем доверия в ту же зону. Проверьте охват по фактически существующим интерфейсам и держите именование в жизненном цикле менеджера соединений, а не правите имена интерфейсов вручную.
Историческое руководство содержит гораздо более старые примеры конфигурации OpenVPN, и его криптографические советы не следует копировать в текущее развёртывание. Заимствуйте вместо этого модель зон и потоков. Криптографическую основу берите из поддерживаемой политики OpenVPN на шлюзе.
Разрешите только тот путь, который вы классифицировали
Широкое разрешение из зоны VPN в LAN — это стартовая схема, а не готовая политика. Запишите разрешённый источник клиента, фактический адрес службы, протокол и порт. Затем прочитайте правила выше и значение зоны по умолчанию, потому что узкое дополнение не отменяет широкого разрешения, которое уже совпадает. Трафик к хосту шлюза — отдельное отношение от трафика, пересылаемого через него.
Трафик между клиентами требует отдельного решения. client-to-client в OpenVPN и routeback в Shorewall оба влияют на то, могут ли клиенты достигать друг друга, и ни один не следует включать только ради работы одного приложения в LAN. Решите, где применяется изоляция, прежде чем проверять её.
Держите обратный путь в том же плане. Служба или её маршрутизатор должны знать, как вернуть трафик в диапазон туннеля, либо проект должен намеренно транслировать источник и в пределах задуманного охвата.
Проверьте, затем докажите оба пути
Проверьте конфигурацию перед любым перезапуском и держите открытой независимую административную сессию на случай, если новая политика окажется ошибочной.
shorewall checkПосле чистой проверки примените конфигурацию и прочитайте, что загрузил Shorewall. Эти чтения описывают работающую политику, а не то, что вроде бы говорит файл.
shorewall show zones
ip route get 192.168.10.20Проверьте один новый разрешённый запрос и один намеренно отклонённый запрос от одного и того же клиента. Успешное рукопожатие OpenVPN доказывает только внешний обмен; разрешённая служба и отклонённый ресурс доказывают ту внутреннюю политику, которую вы задумали. Затем переподключите клиента и повторите, потому что имя и адрес интерфейса туннеля могут меняться между сеансами. Если результат отличается, исправьте охват зоны, а не расширяйте правило.