Я работаю Ubuntu server 22.04и имею необычную проблему переадресации портов с локальной машиной. Эта машина имеет два интерфейса Ethernet, а подключенный enp1s0интерфейс имеет IP-адрес 192.168.1.50. Полная конфигурация IP следующая:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:e0:4f:68:02:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.50/24 metric 100 brd 192.168.1.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 240f:74:de92::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba::d1e/128 scope global dynamic noprefixroute
valid_lft 35597sec preferred_lft 35597sec
inet6 fd41:d8b6:99ba:0:2e0:4fff:fe68:2bb/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 240f:74:de92:0:2e0:4fff:fe68:2bb/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 98462sec preferred_lft 98462sec
inet6 fe80::2e0:4fff:fe68:2bb/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 00:e0:4c:68:01:6e brd ff:ff:ff:ff:ff:ff
altname enp2s0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:55:86:e6:e5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
Я настроил правила переадресации портов для своего маршрутизатора, чтобы все входящие пакеты TCP или from wan to port 22211UDPforwarded to lan 192.168.1.50 port 22211
В своей ufwконфигурации я разрешил маршрутизацию этого порта:
$ sudo ufw status
[sudo] password for *
Status: active
To Action From
-- ------ ----
22211/tcp ALLOW Anywhere
22211/tcp (v6) ALLOW Anywhere (v6)
Теперь, если я запущу простой сокет netcat ( nc -l -p 22211) для этого порта, я смогу без проблем связаться с ним telnetчерез другую машину в локальной сети. Вот tcudumpлог, когда я подключаюсь по telnet с другой локальной машины. Я подключаюсь, отправляю письмо aи нажимаю Enter:
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:01:48.350024 IP (tos 0x0, ttl 64, id 59572, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [S], cksum 0x527d (correct), seq 3440167578, win 32120, options [mss 1460,sackOK,TS val 3772353734 ecr 0,nop,wscale 7], length 0
21:01:48.350139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.50.22211 > 192.168.1.196.38840: Flags [S.], cksum 0x3a60 (correct), seq 495600843, ack 3440167579, win 65160, options [mss 1460,sackOK,TS val 102903428 ecr 3772353734,nop,wscale 7], length 0
21:01:48.351892 IP (tos 0x0, ttl 64, id 59573, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [.], cksum 0x66b7 (correct), seq 1, ack 1, win 251, options [nop,nop,TS val 3772353737 ecr 102903428], length 0
21:01:50.698846 IP (tos 0x0, ttl 64, id 59574, offset 0, flags [DF], proto TCP (6), length 55)
192.168.1.196.38840 > 192.168.1.50.22211: Flags [P.], cksum 0xf275 (correct), seq 1:4, ack 1, win 251, options [nop,nop,TS val 3772356082 ecr 102903428], length 3
Но когда я пробую telnet-форму за пределами моей локальной сети, по какой-то причине соединение так и не устанавливается. Долгое время я был уверен, что моя конфигурация переадресации портов отключена (хотя тот же маршрутизатор переадресовывает другие порты на другую машину в моей локальной сети без проблем, и я по сути просто отзеркалил конфигурацию на другой порт), но, как вы можете видеть из tcpdumpлогов ниже, пакеты приходят на enp1s0интерфейс:
$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:05.448829 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x4448 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560510789 ecr 0,sackOK,eol], length 0
20:58:06.593532 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x405f (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560511790 ecr 0,sackOK,eol], length 0
20:58:07.613818 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x3c76 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560512791 ecr 0,sackOK,eol], length 0
20:58:08.603603 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x388c (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560513793 ecr 0,sackOK,eol], length 0
20:58:09.563590 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
126.33.109.168.36371 > 192.168.1.50.22211: Flags [S], cksum 0xcd21 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560514795 ecr 0,sackOK,eol], length 0
Я также вижу, что netcat прослушивает все интерфейсы (часть 0.0.0.0):
$ sudo ss -tulpn | grep 22211
tcp LISTEN 0 1 0.0.0.0:22211 0.0.0.0:* users:(("nc",pid=3344,fd=3))
Таблица маршрутизации выглядит следующим образом:
$ sudo route -vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 enp1s0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp1s0
192.168.1.1 0.0.0.0 255.255.255.255 UH 100 0 0 enp1s0
Итак, я не понимаю, почему пакеты, поступающие из внешней сети, никогда не достигают локального сокета в порту 22211... Есть ли какие-то дополнительные настройки брандмауэра, которые мне следует настроить?
Редактировать: интересно, что действительно ping 8.8.8.8истекает время ожидания (хотя, например, ping google.com работает нормально)
решение1
TL;DR
Если что-то сложное не работает, сначала убедитесь, что основные элементы работают правильно.
Более длинная версия
Преамбула
Это хороший пример того, как задавать вопрос.
Имеется справочная информация, например, что на компьютере установлена ОС Ubuntu 22.04, а также имеются два интерфейса Ethernet.
Предоставляется подробная информация, например, информация о конфигурации IP.
Показаны как рабочие, так и нерабочие примеры.
Устранение проблемы.
Исправьте недоразумения.
Автор публикации заявил: «Итак, я не понимаю, почему пакеты, поступающие из внешней сети, никогда не достигают локального сокета в порту 22211». Когда данные показывали, что пакеты поступают, это были ответы, которые не отправлялись из этого интерфейса.
OP сказал, что у него два интерфейса. Информация об ip показывает, что второй интерфейс не работает, но, может быть, машина ожидала отправить ответ с другого интерфейса?
Первый запрос дополнительной информации.
«Показывает ли таблица маршрутизации, что маршрут к 126.33.189.168 проходит через интерфейс, который активен (enp1s0)?» OP ответил, добавив в таблицу маршрутизации, а также сказал
«Я добавил информацию о таблице маршрутизации в исходное сообщение. Также я убедился, что другой интерфейс eno1 отключен, но, похоже, никаких изменений не произошло»
Второй запрос дополнительной информации.
Таблица маршрутизации имела символические имена, а не числовые адреса. Без знания сопоставления это было не слишком полезно, поэтому
- «Не могли бы вы изменить редактирование так, чтобы вывод
sudo route -vnотображал числовые значения?»
Задавайте вопросы так, чтобы это было естественно для отвечающего.
В одном из комментариев предлагалось использовать ip routeвместо route -vn. Я использовал ip routeего годами и утверждал, что это лучший инструмент. Вопрос, который следует задать, заключается в следующем: «Мы пытаемся научить OP лучшим инструментам или пытаемся помочь ему решить его проблему?». Я думаю, что введение новых инструментов будет отвлекать.
Второй запрос дополнительной информации - продолжение.
«Можете ли вы также подтвердить, что вы можете пропинговать какой-то известный адрес из 192.168.1.50, например, 8.8.8.8?» Это вызвало ответ
«Вы правы, по какой-то причине ping 8.8.8.8 не проходит! Но ping google.com проходит нормально».
Отладка почему ping google.comработает
- «А какой IP-адрес выбирает ping google.com? (Он показан в первой строке.) Похоже, вы отгородили себя брандмауэром от IPv4, но при этом у вас по-прежнему полностью функционирует IPv6».
Я бы не стал использовать этот термин firewalled. Поскольку таблица маршрутизации показывает 2 маршрута по умолчанию с разными метриками, это почти наверняка проблема маршрутизации.
Третий запрос дополнительной информации.
У большинства людей есть только одно подключение к Интернету, но постарайтесь не делать необоснованных предположений.
- «Вы планируете иметь 2 маршрутизатора, каждый из которых сможет выйти в Интернет (возможно, с двумя разными интернет-провайдерами)?»
когда ответ пришел отрицательный, нужно было просто сказать OP исправить проблему с маршрутизацией (используя знакомую ему команду), и все заработало. Предвосхищение ответа и включение инструкций в вопрос экономит задержку.
- «Возможность пинговать 8.8.8.8 — ваша самая важная проблема. Решение этой проблемы может решить все остальное».
Реальная проблема.
когда пакетам нужно было выйти в Интернет, а не в локальную сеть, им было сказано пройти через несуществующую машину.
Чтобы отправить пакеты на эту несуществующую машину, хост отправлял ARP-пакеты, на которые не получал ответа.
в конце концов хост прекратил попытки связаться с несуществующей машиной и сообщил об ошибке в ответ на команду ping или не отправил подтверждение входящему соединению.
Исправление таблицы маршрутизации для отправки пакетов в Интернет по правильному адресу заставило все работать.