Как я AWS Client VPN ублажал
Это их marketese для OpenVPN. В-общем есть возможность попасть в любую VPC Subnet, используя OpenVPN. При этом документация дебильная, одни примеры без описания того, что вообще у нас происходит. Так что делюсь своими открытиями.
Для простоты рассмотрим VPC полностью приватную без какого-либо доступа наружу. Такой "airgapped" сегмент в котором для простоты сидит инстанс EC2. И мы на него заходим по SSH.
В этой схеме у нас есть аж 3 сидра:
1. CIDR для VPN-клиента и его пира, то есть для концов VPN.
2. CIDR для VPC
3. CIDR для сегмента к которому мы подключаемся. Всегда содержится внутри блока (2)
Первое открытие - это что блок (1) полностью "служебный", пакетов с адресами из этого блока никто в VPC не увидит.
Общая схема такая:
клиент - адрес из (1) - туннель - адрес из (1) - 1-to-1 NAT - адрес из (3) - целевой сегмент - адрес из (3) - инстанс
Она хороша тем, что удаленный хост может "прикинуться" обычным хостом из локалки. Ну то есть вот допустим у вас есть 192.168.20.22 и там сетевая шара принимающая трафик только из своего 192.168.20.0/24. В этом случае вы можете используя эту схему подобавлять удаленных хостов к локальным, не меняя фаерволл на шаре.
Далее, в этом 1-to-1 NAT есть свой фаерволл на входящем трафике, представляющий из себя просто белый список сидров, которые пропускать. В этот список по дефолту добавляется (2) но можно и дополнительно чего-то подобавлять. Например если вы хотите использовать это и AWS NAT Gateway как очень дорогой способ подмены IP, туда надо добавить 0.0.0.0/0. В терминах AWS этот список называется Authorization Rules.
Второе открытие - что эти authorization rules аж никак не влияют на маршруты, выдаваемые клиенту. Ну то есть вы можете дать 0.0.0.0/0 а там клиент пусть сам решит добавлять ли какие-то маршруты или нет. Преимущества authorization rules в том, что разным пользователям OpenVPN можно давать разные сетевые права доступа.
Маршруты же выдаются через Routes, в стиле OpenVPN push route. Они в свою очередь никак не связаны с Authorization Rules, кроме того что по умолчанию и там и там стоит (2).
Дальше, внутри VPC все хосты обмазаны фаерволлами в виде Security Groups:
- 1-to-1 NAT - адрес из (3) - sg - целевой сегмент - sg - адрес из (3) - инстанс
Соответственно, чтобы до хоста доходил SSH (или пинг!), секьюрити группа VPN-эндпоинта должна разрешать исходящий SSH/ICMP, а секьюрити группа инстанса - входящий. SG это стейтлесс conntrack firewall, так что related трафик ака противоположный открывается сам.
Ну и третье открытие заключается в том что дефолтовые секьюрити группы в VPC открыты на выход, но закрыты на вход. Ну и чтобы открыть на вход указывать (1) бесполезно так как у пакета исходящий адрес будет уже после NAT из (2).
Для простоты рассмотрим VPC полностью приватную без какого-либо доступа наружу. Такой "airgapped" сегмент в котором для простоты сидит инстанс EC2. И мы на него заходим по SSH.
В этой схеме у нас есть аж 3 сидра:
1. CIDR для VPN-клиента и его пира, то есть для концов VPN.
2. CIDR для VPC
3. CIDR для сегмента к которому мы подключаемся. Всегда содержится внутри блока (2)
Первое открытие - это что блок (1) полностью "служебный", пакетов с адресами из этого блока никто в VPC не увидит.
Общая схема такая:
клиент - адрес из (1) - туннель - адрес из (1) - 1-to-1 NAT - адрес из (3) - целевой сегмент - адрес из (3) - инстанс
Она хороша тем, что удаленный хост может "прикинуться" обычным хостом из локалки. Ну то есть вот допустим у вас есть 192.168.20.22 и там сетевая шара принимающая трафик только из своего 192.168.20.0/24. В этом случае вы можете используя эту схему подобавлять удаленных хостов к локальным, не меняя фаерволл на шаре.
Далее, в этом 1-to-1 NAT есть свой фаерволл на входящем трафике, представляющий из себя просто белый список сидров, которые пропускать. В этот список по дефолту добавляется (2) но можно и дополнительно чего-то подобавлять. Например если вы хотите использовать это и AWS NAT Gateway как очень дорогой способ подмены IP, туда надо добавить 0.0.0.0/0. В терминах AWS этот список называется Authorization Rules.
Второе открытие - что эти authorization rules аж никак не влияют на маршруты, выдаваемые клиенту. Ну то есть вы можете дать 0.0.0.0/0 а там клиент пусть сам решит добавлять ли какие-то маршруты или нет. Преимущества authorization rules в том, что разным пользователям OpenVPN можно давать разные сетевые права доступа.
Маршруты же выдаются через Routes, в стиле OpenVPN push route. Они в свою очередь никак не связаны с Authorization Rules, кроме того что по умолчанию и там и там стоит (2).
Дальше, внутри VPC все хосты обмазаны фаерволлами в виде Security Groups:
- 1-to-1 NAT - адрес из (3) - sg - целевой сегмент - sg - адрес из (3) - инстанс
Соответственно, чтобы до хоста доходил SSH (или пинг!), секьюрити группа VPN-эндпоинта должна разрешать исходящий SSH/ICMP, а секьюрити группа инстанса - входящий. SG это стейтлесс conntrack firewall, так что related трафик ака противоположный открывается сам.
Ну и третье открытие заключается в том что дефолтовые секьюрити группы в VPC открыты на выход, но закрыты на вход. Ну и чтобы открыть на вход указывать (1) бесполезно так как у пакета исходящий адрес будет уже после NAT из (2).