Переадресация портов через 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.

Другие вопросы по тегам