☰

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

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

Во-первых, это не проблема переадресации портов. Запустив tcpdump, я вижу, что запросы поступают на сервер Debian, а затем они останавливаются.

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

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

яделатьесть маршрутизация и iptables. Я использую эту машину для торрентов + VPN, поэтому я использую маршрутизацию, чтобы все работало. Маршрутизация должна держать PleX подальше от tun0, интерфейса VPN, а iptables должен не давать пользователю debian-transmission использовать что-либо, кроме 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

решение1

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

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

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

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

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

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

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

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

Связанный контент