(no subject)
К этому посту: по-моему, эту задачку сегодня вполне несложно решить с помощью on-demand overlay network, типа всяких SDN или FortiGate ADVPN.
То есть, допустим, таким вот образом:
0. У нас есть сеть со множеством файерволлов, которые находятся под управлением разных людей, но принадлежат одной организации и потому доверяют друг другу.
1. Юзер коннектится на файерволл-А по VPN. Файерволл-А проверяет его identity, список групп Active Directory и т.д., и даёт подключиться.
2. Юзер посылает пакет, который, как определяет файерволл-A, предназначен для сети за файерволлом-Б. Файерволл-A строит туннель (GRE, VXLAN, IPsec - неважно) к файерволлу-Б, и как часть метаинформации передаёт детали identity юзера - имя, SID, список групп и т.д. Инкапсулирует пакет и передаёт по этому туннелю.
3. Файерволл-Б проделывает свои проверки этой identity (если нужно; запрашивает сам список групп по LDAP, например), принимает пакет по туннелю и дальше сам решает, что с ним делать, на основе собственных политик.
4. Если пакет передан и на него пришёл ответ, то файерволл-Б отсылает ответ по тому же туннелю.
5. В случае мультикаста туннели строятся на все файерволлы; ну или же на те, за которыми есть зарегистрированные получатели этой группы, если в ходу протокол построения деревьев для мультикаста.
Таким образом:
- каждый файерволл может выстраивать свои собственные политики на основе групп или другой юзерской информации, а не IP-адресов;
- каждый файерволл может быть VPN-гейтом; любой юзер может подключаться на любой из них или на несколько сразу (см. чекпойнтовый Secondary Connect, к примеру).
- каждый пакет от VPN-клиента мы можем привязать к юзерской личности.
Недостатки:
- первые пакеты могут потеряться или прийти с большой задержкой.
- ещё?..
Интересно, уже имплементировал кто?
То есть, допустим, таким вот образом:
0. У нас есть сеть со множеством файерволлов, которые находятся под управлением разных людей, но принадлежат одной организации и потому доверяют друг другу.
1. Юзер коннектится на файерволл-А по VPN. Файерволл-А проверяет его identity, список групп Active Directory и т.д., и даёт подключиться.
2. Юзер посылает пакет, который, как определяет файерволл-A, предназначен для сети за файерволлом-Б. Файерволл-A строит туннель (GRE, VXLAN, IPsec - неважно) к файерволлу-Б, и как часть метаинформации передаёт детали identity юзера - имя, SID, список групп и т.д. Инкапсулирует пакет и передаёт по этому туннелю.
3. Файерволл-Б проделывает свои проверки этой identity (если нужно; запрашивает сам список групп по LDAP, например), принимает пакет по туннелю и дальше сам решает, что с ним делать, на основе собственных политик.
4. Если пакет передан и на него пришёл ответ, то файерволл-Б отсылает ответ по тому же туннелю.
5. В случае мультикаста туннели строятся на все файерволлы; ну или же на те, за которыми есть зарегистрированные получатели этой группы, если в ходу протокол построения деревьев для мультикаста.
Таким образом:
- каждый файерволл может выстраивать свои собственные политики на основе групп или другой юзерской информации, а не IP-адресов;
- каждый файерволл может быть VPN-гейтом; любой юзер может подключаться на любой из них или на несколько сразу (см. чекпойнтовый Secondary Connect, к примеру).
- каждый пакет от VPN-клиента мы можем привязать к юзерской личности.
Недостатки:
- первые пакеты могут потеряться или прийти с большой задержкой.
- ещё?..
Интересно, уже имплементировал кто?