Действительно странная проблема Debian: невозможно подключиться к каким-либо службам, запущенным в Debian, с любого публичного IP, отлично работает с частными IP

Question

Прежде всего, это не проблема переадресации портов. Запустив tcpdump, я вижу, как запросы поступают на сервер debian, а затем они останавливаются.

Мой сервер Debian работает как Apache, так и PleX. Если я подключаюсь к серверу Debian, используя 192.168.1.210, он работает безупречно. Я могу видеть веб-страницы, и я могу смотреть из PleX.

Если я покидаю свою сеть, скажем, я иду в дом друзей, я тоже не могу получить доступ. Используя tcpdump, я вижу, как пакеты попадают на сервер, но это все. То же самое с canyouseeme.org.

У меня есть некоторые маршрутизации и Iptables на месте. Я использую эту машину для торрент + VPN, поэтому я использую маршрутизацию, чтобы все работало. Предполагается, что маршрутизация удерживает PleX вдали от tun0, интерфейса VPN, а iptables должен удерживать пользовательскую передачу debian от использования чего-либо, кроме tun0.

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

Iptables:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

Answer 1

Вероятно, проще всего описать, что происходит на примере.

Допустим, IP-адрес вашего маршрутизатора NAT равен 1.1.1.1, а IP-адрес вашего друга - 2.2.2.2. Для простоты предположим, что ваш друг не находится за маршрутизатором nat (это делает пример немного более сложным, если он есть, но диоды не принципиально изменяют проблему. Я также предполагаю, что переадресация порта направлена от порта 80 на вашем внешнем IP к порту 80 на коробке Debian.

Компьютер вашего друга отправляет пакет синхронизации с адресом источника 2.2.2.2, случайно выбранным портом источника (скажем, 12345), адресом назначения 1.1.1.1 и портом назначения 80

Пакет достигает вашего NAT, он ищет порт вперед и меняет целевой IP на 192.168.1.210. Исходный IP остается как 2.2.2.2, порты остаются прежними. Отображение создается так, что обратный перевод может быть выполнен при возврате пакетов, пока это хорошо.

Пакет достигает вашего сервера. Он доставляется в стек TCP, который создает ответный пакет. Как обычно, когда пакет отвечает на источник и назначение меняются местами. Таким образом, пакет имеет адрес источника 192.168.1.210, адрес назначения 2.2.2.2, порт источника 80 и порт назначения 12345.

Ответ покидает стек TCP и попадает в iptables. Ваши правила выполняют сопоставление UID, поэтому сопоставление владельца работает правильно, пакет должен пройти через него.

Затем он попадает в таблицу маршрутизации. Который отправляет это вниз по VPN. Он обращается к NAT в VPN, который каким-то образом изменяет его источник, возвращается к вашему другу и сбрасывается из-за неправильного адреса источника.

Возможные исправления: 1: Добавьте IP-адрес своих друзей в таблицу маршрутизации, очевидно, он не очень хорошо масштабируется и может вызвать утечку торрент-трафика. 2: Если ваш nat box - это правильная система linux, должна быть возможность настроить его для изменения источника, а также назначения входящих соединений. Таким образом, ваш торрент-бокс воспринимает NAT-блок как источник, а не как систему ваших друзей в Интернете. 3: использовать функции "расширенной маршрутизации" в linux для маршрутизации на основе исходного порта. К сожалению, расширенные функции маршрутизации очень мощны, но также сложны для понимания. Если вы хотите получить больше информации о том, как идти по этому маршруту, ознакомьтесь с "linux advanced маршрутизацией и руководством по управлению трафиком"