- Вопрос или проблема
- Описание
- Полный список NAT
- tcpdump для ssh к ec2
- tcpdump для соединения psql с RDS
- Маршруты на VPN-сервере
- Примененные правила iptables
- Попытанные правила, которые не сработали
- Ответ или решение
- Ответ на вопрос о правилах маскировки iptables, применимых к некоторым входящим соединениям, но не ко всем
- Описание проблемы
- Что происходит?
- Рекомендации
- Заключение
Вопрос или проблема
Описание
У меня есть правило NAT для IP Tables, которое я пытаюсь применить к входящим соединениям. У меня есть сервер OpenVPN, работающий на экземпляре EC2, используя sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
- Я могу подключиться к VPN-серверу через его публичный IP и его приватный IP.
- Я могу подключаться к экземплярам EC2 в приватных подсетях только по их приватным IP.
- Я могу подключаться к экземпляру RDS с других экземпляров EC2 в VPC.
- Я не могу подключиться к своей базе данных RDS через VPN-сервер.
- Я не могу подключиться к своей базе данных RDS через свой локальный ноутбук, проксируя трафик через соединение OpenVPN.
Моя основная проблема заключается в том, что часть моего исходящего трафика правильно маскируется на 10.21.0.0/16, который является CIDR моего VPC на интерфейсе ens05, а часть трафика пытается выходить через интерфейс OpenVPN tun0 на 10.8.0.1. Я не знаю, почему это происходит.
Полный список NAT
ubuntu@ip-10-21-6-191:~$ sudo iptables -L -v -t nat --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 9740 packets, 782K bytes)
num pkts bytes target prot opt in out source destination
1 7 476 MASQUERADE all -- any any ip-10-8-0-0.us-west-2.compute.internal/24 anywhere
tcpdump для ssh к ec2
Это здесь, чтобы показать, что трафик отправляется с приватного IP-адреса для исходящего трафика экземпляра ec2 и поступает как 10.8.0.2 для входящего трафика OpenVPN сервера.
$ sudo tcpdump -v -A -n -i any dst 10.21.162.20 and port 22
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
06:13:23.505062 tun0 In IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
10.8.0.2.53847 > 10.21.162.20.22: Flags [SEW], cksum 0xdc1a (correct), seq 2279926992, win 65535, options [mss 1400,nop,wscale 6,nop,nop,TS val 2189220490 ecr 0,sackOK,eol], length 0
EH.@..@.@..=
...
....W.....................x.......
.|..........
06:13:23.505108 ens6 Out IP (tos 0x48, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)
10.21.175.81.53847 > 10.21.162.20.22: Flags [SEW], cksum 0x2cbe (correct), seq 2279926992, win 65535, options [mss 1400,nop,wscale 6,nop,nop,TS val 2189220490 ecr 0,sackOK,eol], length 0
EH.@..@.?...
tcpdump для соединения psql с RDS
Это здесь, чтобы показать, что трафик поступает на 10.8.0.2 и выходит как 10.8.0.2. И входящий, и исходящий трафик проходит через tun0, а не через ens05, который является моим реальным приватным интерфейсом.
sudo tcpdump -v -A -n -i any port 5432
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
06:13:43.704192 tun0 In IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
10.8.0.2.53850 > 10.21.187.190.5432: Flags [SEW], cksum 0x7db8 (correct), seq 2202549979, win 65535, options [mss 1400,nop,wscale 6,nop,nop,TS val 2513283422 ecr 0,sackOK,eol], length 0
E..@..@[email protected].
...
....Z.8.H>.........}......x.......
...^........
06:13:43.704244 tun0 Out IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)
10.8.0.1.53850 > 10.21.187.190.5432: Flags [SEW], cksum 0x7db9 (correct), seq 2202549979, win 65535, options [mss 1400,nop,wscale 6,nop,nop,TS val 2513283422 ecr 0,sackOK,eol], length 0
E..@..@.?.k.
...
....Z.8.H>.........}......x.......
...^........
06:13:44.704362 tun0 In IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
10.8.0.2.53850 > 10.21.187.190.5432: Flags [S], cksum 0x7a8f (correct), seq 2202549979, win 65535, options [mss 1400,nop,wscale 6,nop,nop,TS val 2513284423 ecr 0,sackOK,eol], length 0
E..@..@[email protected].
...
....Z.8.H>.........z......x.......
...G........
Маршруты на VPN-сервере
ubuntu@ip-10-21-6-191:~$ route -n
Таблица маршрутизации ядра IP
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.21.0.1 0.0.0.0 UG 100 0 0 ens5
0.0.0.0 10.21.160.1 0.0.0.0 UG 200 0 0 ens6
0.0.0.0 10.21.160.1 0.0.0.0 UG 1003 0 0 ens6
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.21.0.0 0.0.0.0 255.255.240.0 U 100 0 0 ens5
10.21.0.0 10.8.0.2 255.255.0.0 UG 0 0 0 tun0
10.21.0.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
10.21.0.2 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
10.21.0.2 10.21.160.1 255.255.255.255 UGH 200 0 0 ens6
10.21.160.0 0.0.0.0 255.255.240.0 U 1003 0 0 ens6
10.21.160.1 0.0.0.0 255.255.255.255 UH 200 0 0 ens6
Примененные правила iptables
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
iptables -I INPUT 1 -i tun0 -j ACCEPT
iptables -I FORWARD 1 -i ens5 -o tun0 -s 10.8.0.0/24 -j ACCEPT
iptables -I FORWARD 1 -i tun0 -o ens5 -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 1 -i ens5 -p udp --dport 1194 -j ACCEPT
Попытанные правила, которые не сработали
iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -o ens5 -j MASQUERADE
Ответ или решение
Ответ на вопрос о правилах маскировки iptables, применимых к некоторым входящим соединениям, но не ко всем
Ваш вопрос касается проблемы с применением правила NAT (Network Address Translation) с маскировкой на сервере OpenVPN, который работает на экземпляре Amazon EC2. Давайте разберемся с вашей проблемой более подробно.
Описание проблемы
Как вы описали, ваше правило маскировки:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADEсрабатывает для некоторых исходящих соединений, но не для всех, особенно для соединений с RDS (Relational Database Service). Вы также заметили, что трафик, исходящий из VPN, идет через интерфейс tun0, в то время как подключение к EC2-инстансам происходит через интерфейс ens05.
Что происходит?
Судя по вашим выводам и TCPdump, у вас есть несколько направлений трафика, и эта проблема может быть связана с маршрутизацией и тем, как вы применяете правила iptables:
-
Маршрутизация: Убедитесь, что маршруты настроены корректно для трафика, следующего к RDS. Ваш VPN должен знать, как достичь сетей, к которым вы пытаетесь подключиться (в данном случае, сети RDS).
-
Настройка iptables: Попробуйте изменить порядок правил в iptables, чтобы убедиться, что они обрабатываются в нужном порядке. Убедитесь, что ваш интерфейс
ens05правильно маршрутизирует трафик к RDS.
Рекомендации
Вот несколько шагов, которые вы можете предпринять для решения этой проблемы:
-
Добавьте правило для всей VPC:
Чтобы убедиться, что ваше правило маскировки также применяется к трафику, идущему черезens05, попробуйте добавить следующее правило:sudo iptables -t nat -A POSTROUTING -o ens05 -s 10.8.0.0/24 -j MASQUERADEЭто правило будет маскировать исходящий трафик от клиентов OpenVPN, когда он проходит через
ens05. -
Проверьте маршрутизацию:
Убедитесь, что у вас есть правильные маршруты на сервере OpenVPN для подключения к вашему RDS. Вам может понадобиться добавить статический маршрут для вашей базы данных RDS. -
Проверьте правила FORWARD:
Убедитесь, что у вас также есть правильные правила для цепочки FORWARD, чтобы разрешить трафик, который возвращается от RDS к клиенту OpenVPN:iptables -I FORWARD -i ens05 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o ens05 -m state --state ESTABLISHED,RELATED -j ACCEPT -
Логирование: Включите логирование в iptables, чтобы понять, блокируется ли трафик каким-либо другим правилом. Например, вы можете добавить следующее правило:
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD: " --log-level 4 -
Тестирование: После изменения правил, выполните тестирование соединений к RDS снова, чтобы проверить, решена ли проблема.
Заключение
Эти шаги должны помочь вам идентифицировать и устранить проблему с маскировкой NAT для некоторых входящих соединений. Тщательно проанализируйте маршруты и порядок применения правил iptables. Если проблема сохранится, пожалуйста, предоставьте дополнительные данные о маршрутизации и iptables, чтобы углубить анализ.