Вчера я разместил вопрос Вот но я думаю, что мои слова были недостаточно ясны. Кстати, этот вопрос не дубликат.
У меня есть настройка AWS VPC, как показано ниже.
ЦЕЛЬ / ПРОБЛЕМА: SSH к серверу A из Интернета. И это не работает.
Сервер A находится в частной подсети, и поэтому я хочу включить iptables NATing на моем экземпляре NAT, чтобы я мог ssh на SErver A напрямую из Интернета
Я выполнил следующую команду на экземпляре NAT:
NAT# iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22
Переадресация IP включена на инстансе NAT:
NAT# sysctl -p
net.ipv4.ip_forward = 1
MASQUERADE работает на экземпляре NAT:
NAT# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 6 packets, 312 bytes)
pkts bytes target prot opt in out source destination
199 16466 MASQUERADE all -- * eth0 10.0.0.0/16 0.0.0.0/0
Группы безопасности AWS настроены правильно, чтобы разрешить различный доступ, необходимый для этого тестового примера.
Исправление проблем:
Я могу telnet от NAT к серверу A на порту 22. Так что доступ в порядке.
Когда я бегу telnet 54.213.116.251 2222
на моем ноутбуке я вижу ниже запись в tcpdump на NAT:
NAT# tcpdump -n -i eth0 dst 10.0.1.243 and port 22
09:59:13.738316 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:16.737009 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:22.775567 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,nop,sackOK], length 0
Это означает, что iptables направляет пакеты на 10.0.1.243
. (Кстати, xxx.xxx.xxx.xxx
публичный IP-адрес моего ноутбука)
Но когда я запускаю tcpdump на сервере A, я не вижу ничего из 10.0.0.54
который является внутренним / частным IP-адресом NAT (И я думаю в этом проблема):
Server A# tcpdump -n src 10.0.0.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
Но если я подключу telnet от экземпляра NAT к серверу A, я увижу хорошие вещи в tcpdump на сервере A (Это означает, что мой общий PREROUTING
Правило не работает должным образом):
Server A# tcpdump -n src 10.0.0.54
05:01:47.500080 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [S], seq 2862522431, win 14600, options [mss 1460,sackOK,TS val 3013083 ecr 0,nop,wscale 7], length 0
05:01:47.501601 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 760676524, win 115, options [nop,nop,TS val 3013083 ecr 12074896], length 0
05:01:47.535720 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 22, win 115, options [nop,nop,TS val 3013092 ecr 12074928], length 0
Вывод:
Из вывода tcpdump на NAT кажется, что Iptables нормально пересылает мои пакеты.
из дампа TCP на сервере A, у меня хорошее соединение NAT с сервером A.
Но в сквозном режиме я не могу подключиться к серверу A со своего ноутбука.
(Кстати, я знаю SSH-туннель и другие хорошие вещи. Но я хочу, чтобы в этом мне помогал только Iptables.)
Наконец-то я его взломал !!!!
В экземпляре NAT мне пришлось изменить следующую команду:
Из:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE
Кому:
iptables -t nat -A POSTROUTING -j MASQUERADE
И ЭТО СРАБОТАЛО !!!!
Итак, я скоро создам новый вопрос по ServerFault, в котором буду спрашивать, каковы преимущества и недостатки использования двух вышеуказанных команд.
2222
inboud из 0.0.0.0/0
в группе безопасности для вашего nat box10.0.1.0
(частная) подсеть должна иметь правило таблицы маршрутов, например: Назначение: 0.0.0.0/0
, Target: "Натуральный ящик"10.0.0.0
(общедоступная) подсеть должна иметь правило таблицы маршрутов, например: Назначение: 0.0.0.0/0
, Target: «Интернет-шлюз»Убедитесь, что у вас есть проверка источника / назначения отключен на сетевом адаптере для вашего NAT-бокса, без него не получится. (Я знаю, что у тебя это уже есть, но это действительно важно, поэтому включите его для будущего зрителя)
Убедитесь, что исходящие пакеты знают, куда идти:
iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE
Убедитесь, что пакеты inboud 2222
правильно перенаправить:
iptables --table nat --append PREROUTING --protocol tcp --dport 2222 --jump DNAT --to-destination 10.0.1.243:22
Эти сообщения очень помогли мне понять AWS NAT. Итак, я начал исследовать, что сделало iptables -t nat -A POSTROUTING -j MASQUERADE
это сработало.
Что ж, ответ, который я нашел, приведенное выше утверждение позволяет блоку NAT использовать NAT IP «LAPTOP» до «10 .0.0.54», в то же время выполняя NAT назначения для 10.0.1.243. В настоящее время ящик частной подсети - это ssh-запрос, поступающий только от устройства NAT. Эта команда фактически снижает безопасность сервера частной подсети. Рекомендуется использовать приведенную ниже команду для точной настройки доступа к частной подсети через ssh и NAT, как указано ниже;
iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE
Немного безопаснее:
iptables -t nat -I PREROUTING -d 52.213.216.251 -j DNAT --to-destination 10.0.1.243:22
iptables -t nat -I POSTROUTING -s 10.0.1.243 -j SNAT --to-source 52.213.216.251