Вопрос или проблема

У меня есть два сервера, подключенных через WireGuard: локальный сервер (ml-server1, IP WireGuard 10.8.0.2) и сервер Oracle Cloud (ml-oracle-server, IP WireGuard 10.8.0.1). Моя цель – использовать ml-oracle-server в качестве шлюза для доступа к службам на ml-server1 без раскрытия публичного IP-адреса локального сервера. Например, доступ по SSH к ml-server1 должен быть доступен через ml-oracle-server:2222.

Детали настройки:

1. Конфигурация WireGuard:

   • Туннель работает (проверено через ssh -p 2222 [email protected] с ml-oracle-server).
   • ml-oracle-server и ml-server1 используют iptables для перенаправления трафика.

2. Правила IPTables:

   • Правила DNAT/MASQUERADE:

# Для TCP iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.8.0.2:2222 iptables -t nat -A POSTROUTING -o wg0 -p tcp -d 10.8.0.2 --dport 2222 -j MASQUERADE

# Для UDP (если необходимо) iptables -t nat -A PREROUTING -p udp --dport 2222 -j DNAT --to-destination 10.8.0.2:2222 iptables -t nat -A POSTROUTING -o wg0 -p udp -d 10.8.0.2 --dport 2222 -j MASQUERADE 

2. • Текущая NAT таблица:

Chain PREROUTING (policy ACCEPT)
target     prot opt source    destination         
DNAT       tcp  --  anywhere anywhere tcp dpt:2222 to:10.8.0.2:2222
DNAT       udp  --  anywhere anywhere udp dpt:2222 to:10.8.0.2:2222

Chain POSTROUTING (policy ACCEPT)
target        prot opt source      destination         
MASQUERADE    all  --  anywhere    anywhere            
MASQUERADE    all  --  anywhere    anywhere            
MASQUERADE    tcp  --  anywhere    10.8.0.2 tcp dpt:2222
MASQUERADE    udp  --  anywhere    10.8.0.2 udp dpt:2222

3. Конфигурация SSH:

   • ml-server1 слушает на 0.0.0.0:2222 (подтверждено в sshd_config).

4. Пересылка ядра:

   • net.ipv4.ip_forward=1 включено и применено.

Проблема:

Подключение извне через ssh -p 2222 user@<ml-oracle-server-public-ip> приводит к Отказ подключения. Однако подключение напрямую с ml-oracle-server к 10.8.0.2:2222 работает.

Проведенные действия по устранению неполадок:

1. Проверена связность WireGuard (успешно).
2. Проверены правила iptables -t nat (выглядят корректно).
3. Подтверждено, что SSH слушает на ml-server1.

Предполагаемые проблемы:

1. Таблица фильтров IPTables: Цепочка FORWARD может блокировать трафик даже после правил NAT.
2. Правила MASQUERADE: Избыточные или некорректно настроенные правила POSTROUTING.

Вопросы:

1. Отсутствуют ли правила фильтрации iptables (например, цепочка FORWARD), разрешающие трафик между интерфейсами (например, с eth0 на wg0)?
2. Корректно ли правила MASQUERADE обрабатывают исходящий NAT для обратного трафика?

Буду признателен за любые советы!

Ответ или решение

Теория:

При использовании WireGuard для соединения двух серверов и дальнейшего выполнения портового перенаправления могут возникать различные сложности, в том числе и проблемы с доступом к сервисам за туннелем. Ваша цель — используя сервер Oracle в качестве шлюза, открыть доступ к сервисам на локальном сервере, скрывая его публичный IP-адрес. Однако, несмотря на таргетированную настройку, проблема «Connection refused» при попытке подключения свидетельствует о наличии конфигурационного или сетевого барьера.

Наиболее типичными причинами могут быть неправильные правила IPTables, особенно в цепочке FORWARD, или ошибки в NAT, такие как некорректные правила MASQUERADE. Также возможно, что вмешиваются конфигурационные ограничения самого WireGuard или неправильно настроена маршрутизация.

Пример:

Посмотрим на вашу текущую конфигурацию IPTables. Правила DNAT и MASQUERADE кажутся корректными: вы перенаправляете TCP и UDP трафик с ml-oracle-server на порт 2222 к ml-server1 через его IP в WireGuard-туннеле. Однако, простой проверкой работы туннеля подключением с ml-oracle-server к ml-server1 не всегда можно исключить все возможные проблемы, которые могут возникнуть при межсетевой маршрутизации.

Помимо NAT-таблицы, важно понимать роль таблицы фильтров IPTables — цепочка FORWARD может предотвратить передачу трафика между интерфейсами, если для неё не заданы соответствующие правила. Так, даже если NAT успешно перенаправляет входящий трафик, он может быть отброшен из-за отсутствия разрешающего правила в FORWARD.

Применение:

Для устранения проблемы следует проверить и настроить следующие элементы:

1. Настройка цепочки FORWARD IPTables: Убедитесь, что в FORWARD цепочке добавлены те самые необходимые правила, которые разрешают передачу трафика между интерфейсами Oracle-сервера и туннеля WireGuard. Для этого выполните:

iptables -A FORWARD -i eth0 -o wg0 -p tcp --dport 2222 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i wg0 -o eth0 -p tcp --sport 2222 -m state --state ESTABLISHED,RELATED -j ACCEPT

Эти правила разрешат передачу трафика TCP на порт 2222 между сетевым интерфейсом и интерфейсом туннеля.

2. Отсутствие ненужных правил MASQUERADE: Поскольку MASQUERADE, как правило, используется для замены исходного адреса, убедитесь, что у вас не дублируются и не конфликтуют правила. Например, убедитесь, что используете исключительно протокол TCP, если UDP не требуется:

iptables -t nat -D POSTROUTING -o wg0 -p udp -d 10.8.0.2 --dport 2222 -j MASQUERADE

3. Убедитесь, что маршрутизация вовремя обновляется: Проверьте, что параметры маршрутизации на сервере Oracle не препятствуют передаче через WG-туннель и учитывают всю нужную информацию о сетях:

ip route show

Должна присутствовать маршрутизация для 10.8.0.0/24 через интерфейс wg0. Убедитесь также, что маршрут по умолчанию корректно настроен.

4. Проверьте логи WireGuard и SSH: Рекомендуется исследовать журналы ошибок и событий, в убружении которых может скрываться причина проблемы. Запустите WireGuard и SSH в режиме отладки для получения более подробной информации.

5. Ошибки в конфигурации SSH: Убедитесь, что SSHD на ml-server1 действительно правильно прослушивает порт 2222 для всех интерфейсов. Возможно, потребуется проверить bind-адреса в /etc/ssh/sshd_config.

Таким образом, ключом к решению данной проблемы является тщательный анализ и настройка правил IPTables, проверка маршрутизации и параметров SSH. Обратите внимание на взаимосвязь всех этих элементов и отладку с целью выявления точного источника проблемы.