Переадресация портов через xinetd в среде NAT
Я работаю над настройкой, которая требует перенаправления запроса, приходящего на один из портов сервера, на порт другого сервера в среде с NAT (пример: все запросы, приходящие на 192.168.1.100:843, должны быть перенаправлены на 192.168.1.200:8443 - оба сервера находятся за выделенным межсетевым экраном и сообщают друг другу все порты.)
Служба работает на сервере 192.168.1.200 с портом 8443. Я настроил переадресацию портов на сервере 192.168.1.100 через xinetd следующим образом.
service serv1
{
bind = 192.168.1.100
protocol = tcp
flags = REUSE
socket_type = stream
port = 843
wait = no
user = root
redirect = 192.168.1.200 8443
}
Теперь, когда я делаю telnet на 192.168.1.100 843 в локальной сети, я могу подключить службу на 192.168.1.200:8443
-> telnet 192.168.1.100 843
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
Но когда я пытаюсь подключиться через публичный IP-адрес 192.168.1.100, я получаю "соединение закрыто"
-> telnet 1.2.3.4 843
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
Connection closed by foreign host.
При выполнении tcpdump я обнаружил, что в последующем запрос не приходит на сам сервер 192.168.1.200.
У меня есть аналогичная настройка, работающая в одном из наших DC, и она работает нормально. Любая идея, если что-то может пойти не так здесь.
Спасибо, Мегананд
2 ответа
После дальнейшего изучения я обнаружил, что он блокировался из-за TCPWrappers. После добавления соответствующих правил он работает нормально.
Следующий добавлен в /etc/hosts.allow
serv1: ALL
Спасибо
Вам необходимо удалить bind
линии, если вы хотите, чтобы он прослушивал все IP-адреса, назначенные хосту.
Это, однако, не может быть полным объяснением вашей проблемы. Если бы это была единственная ошибка, которую вы допустили, то при подключении к другому IP-адресу было бы отказано в соединении, а не в установленном соединении с последующим отключением.
Что-то еще может прослушивать тот же номер порта на другом IP-адресе. Это может быть даже другое xinetd
оказание услуг. Если у вас есть другой xinetd
Сервис, который выглядит примерно так, может объяснить проблему:
service serv2
{
bind = 192.0.2.42
protocol = tcp
flags = REUSE
socket_type = stream
port = 843
wait = no
user = root
redirect = 192.168.1.200 61868
}
Здесь различия в том, что другой прослушивает другой IP (но с тем же номером порта) и подключается к другому номеру порта, который закрыт. Если это то, что вы сделали, то соединения с другим IP-адресом получат установленное соединение, которое xinetd
должен закрыть, как только он поймет, что целевой порт для redirect
закрыто.
Последняя часть просто угадала. Если вы бежите netstat -ntlpW
, вы должны быть в состоянии увидеть, что действительно слушает на том другом IP.