Мульти-доменная система - это система с несколькими IP-интерфейсами. Эти интерфейсы могут находиться в одной и той же или в разных подсетях. Сегодня я хочу рассмотреть такие протоколы, как FTP и NDMP. В обоих протоколах сервер принимает соединение от клиента, а затем устанавливает новое соединение обратно к клиенту. На многодоменной системе именно это новое соединение вызывает все проблемы.
В обоих протоколах IP-адрес источника НЕ основан на IP-адресе, к которому изначально подключался клиент. Вместо этого он основан на интерфейсе, связанном со шлюзом, который используется для обратной связи с клиентом.
Например, учитывая следующие интерфейсы и таблицу маршрутизации
ifconfig -all

Number of interface(s) under IP: 5

%phx_vos#loop.m16: <UP, LOOPBACK, RUNNING>
127.0.0.1 netmask 0xff000000

%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE>
172.16.1.50 netmask 0xffffff00 broadcast 172.16.1.255

%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE>
192.168.77.50 netmask 0xffffff00 broadcast 164.152.77.255

ready 15:33:51


route print

Default Gateway: 192.168.77.1
ready 15:33:57
Клиент с IP-адресом 10.1.1.1 подключается к 172.16.1.50, называя это соединение "A". Для отправки пакетов на 10.1.1.1 модуль должен использовать шлюз по умолчанию, который находится в сети 192.168.77.0/24 и поэтому использует интерфейс 192.168.77.50. Он использует этот интерфейс для ВСЕГО трафика на 10.1.1.1 для соединения "A"; но IP-адрес в TCP-заголовке будет 172.16.1.50, потому что это IP-адрес, к которому клиент подключен в соединении A . Однако, когда модуль создает новое соединение с 10.1.1.1, соединение "B", STCP по умолчанию выберет 192.168.77.50 в качестве IP-адреса источника. Это происходит потому, что именно к этому интерфейсу подключен шлюз. Приложение может переопределить это, но ни FTP, ни NDMP не делают этого.
Основное внимание уделяется конфигурации брандмауэров и списков доступа на маршрутизаторах. Если клиентский брандмауэр или ACL маршрутизатора настроены на разрешение только соединений с 172.16.1.50, соединение с 192.168.1.50 будет неудачным. Решением будет либо создание маршрута к 10.1.1.1, используя маршрутизатор в подсети 172.16.1.0/24 (конечно, выбранный маршрутизатор должен быть способен достигать 10.1.1.1), либо создание брандмауэра и списков доступа маршрутизатора, но его настройка должна быть изменена, чтобы разрешить 192.168.1.50.
Вы можете протестировать это с помощью следующего скрипта
stcp_calls
socket
connect -name 10.1.1.1 -port N
socket
bind -name 172.16.1.50 -port 0
connect -name 10.1.1.1 -port N
Конечно, вы должны заменить 10.1.1.1 на действительный IP адрес клиента, а 172.16.1.50 на IP адрес, с которым клиент тоже подключается. Порт N должен быть каким-то портом, который открыт на клиенте и разрешен брандмауэрами и ACL маршрутизаторами.
При первом подключении будет использоваться IP-адрес по умолчанию, при втором подключении - 172.16.1.50. Если первое соединение заканчивается (это займет около минуты) или возвращается немедленно с ошибкой об отказе в соединении, но второе соединение работает (все, что вы увидите, это подсказку "stcp:"), вы можете быть уверены, что есть проблема с ACL брандмауэром или маршрутизатором, которую нужно будет решить.

© 2020 Stratus Технологии.