Странные подвисания "проброшенных" портов

nerot · 07.07.2020

Добрый день всем.
Прошу помочь с вопросом о работе через шлюз, который работает на AL SE 1.6 (smolensk). С Линуксом, впринципе, знаком очень плохо.
На шлюзе имеется 2 сетевых интерфейса eth2 и eth3 (их всего 4, но задействованы только эти два).
Между ними проброшены несколько TCP портов, со всей сети eth2 на конкретный адрес в eth3 используя iptables.

eth2 сконфигурирован так:

Код:

IP4.ADDRESS[1]:                         10.107.131.19/26
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 10.107.131.0/26, nh = 0.0.0.0, mt = 101
IP4.ROUTE[2]:                           dst = 10.107.0.0/16, nh = 10.107.131.62, mt = 1

eth3 так:

Код:

IP4.ADDRESS[1]:                         192.168.1.111/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100

Сами правила прикрепил во вложение.

В общем то, проблем в работе сети поначалу нет. Работают и RDP и файлы перекинуть можно и сервер Oracle доступен, но время от времени начинаются какие-то затупы по этим портам: соединение устанавливается только через несколько минут, а бывает и так, что вообще не устанавливается (timeout), причем это происходит сразу по всем проброшенным портам. Если спамить команду tnsping для проверки связи с прослушивателем СУБД Oracle (к которому проброшен один из портов), то из 10 раз, 1 или 2 раза приходит ответ ОК (0 мс), раз 5-6 приходит ОК (от 300 до 3000 мс), и остальные разы вообще не приходит ответа.
Происходит такое 1-2 раза в неделю, но может и по несколько раз в день встречаться, а может и за 2 месяца ни разу. Лечится перезагрузкой всего шлюза и до нового "затупа" (снова может пройти от 1 дня до нескольких недель). Последнее время уж очень зачастилось такое и уже надоело, хочется вылечить проблему, но не могу определить ее.
Такое ощущение, что какая-то сетевая служба на Астре начинает подвисать и из-за нее теряются пакеты. Не исключаю и проблемы со стороны самой сети WAN, но после их исчезновения (если дело вообще в них) шлюз продолжает тупить с пробросанными портами до перезагрузки. В этот момент сам шлюз доступен по SSH со стороны обоих сетей и соединение стабильное, со шлюза в обе сети пинг идет хороший, ровный, пакеты не теряются.

Может есть у кого какие мысли, где и что можно посмотреть/подшаманить ?

oko · 07.07.2020

to nerot
А вам принципиально, чтобы коннект извне в локалку для вашей локалки выглядел как коннект с вашего шлюза (читай, точно ли нужен обратный NAT с подменой каждого удаленного IP-адреса на внутренний IP-адрес шлюза)?
Вообще, модуль экстрасенсорики подсказывает, что у вас кошки скребутся Cisco-стиль описания правил iptables - первые два правила NAT в обе стороны (извне внутрь и изнутри вовне). Так-то оно тоже работает, но хуже. Потому что операции с NAT всегда дают бОльшую нагрузку на "сетевую подсистему" (процессор, память, буферы обмена, очереди и проч.). К тому же, они не особо нужны, раз вы далее применяете PAT (обратный NAT по конкретным портам)...

#!/bin/bash

# Внешний интерфейс
export WAN=eth2
export WAN_IP=10.107.131.19

# Локальная сеть
export LAN=eth3
export LAN_IP=192.168.1.111
export LAN_IP_RANGE=192.168.1.0/24

# Сервер
export SERVER=192.168.1.1

# Очищаем правила
iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -X
iptables -t nat -X
iptables -t mangle -X

# Запрещаем все, что не разрешено
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Разрешаем исходящие со шлюза
iptables -P OUTPUT -j ACCEPT

# Разрешаем localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -i lo -j ACCEPT

# Включаем маскарадинг для трафика из внутренний сети вовне
iptables -t nat -A POSTROUTING -o $WAN -s $LAN_IP_RANGE -j MASQUERADE

# Разрешаем установленные подключения (доступ к самому шлюзу, доступ и внутренней сети вовне, доступ извне во внутреннюю сеть)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем подключения извне на нужные порты внутреннего сервера и включаем проброс портов
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 3389 -d $WAN_IP -j DNAT --to-destination $SERVER
iptables -A FORWARD -i $WAN -p tcp -m tcp -d $SERVER --dport 3389 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 445 -d $WAN_IP -j DNAT --to-destination $SERVER
iptables -A FORWARD -i $WAN -p tcp -m tcp -d $SERVER --dport 445 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 1521 -d $WAN_IP -j DNAT --to-destination $SERVER
iptables -A FORWARD -i $WAN -p tcp -m tcp -d $SERVER --dport 1521 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -d $WAN_IP -j DNAT --to-destination $SERVER
iptables -A FORWARD -i $WAN -p tcp -m tcp -d $SERVER --dport 8080 -j ACCEPT

# открываем доступ к портам (на самом шлюзе!)
# желательно открывать их, фильтруя по IP-адресу источника (-s) - например, доступ по SSH с конкретного внутреннего IP-адреса машины администратора
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

# Сохраняем правила
/sbin/iptables-save > /etc/iptables.rules

Для еще большего снижения нагрузки рекомендуется как у вас, т.е. без MASQUERADE (заметил, что он комментирован), а с явным NAT на WAN-адрес. Но я не стал заморачиваться, ага

Если тест пройдет успешно - добавьте ваши правила на блок пакетов с 0 длиной, SYN-пакетов и проч. в цепочки filter-INPUT и filter-FORWARD...

UPD - Подправил формулировки и конфиг, добавив правила PREROUTING. Ошибся в первый раз, не доглядел...
UPD2 - цепочка NAT всегда отрабатывает ДО правил фильтрации, соответственно в последних строках цепочки filter-INPUT убрал подключения на RDP-порт, SMB-порт и проч. Это уже сделано в filter-FORWARD выше...

oko · 07.07.2020

to nerot
Пока писал конфиг, появилось два подозрения...
Primo, объясните детально схему сети и соединений: кто куда должен доступ получать (извне вовнутрь на какие ресурсы и по каким портам, изнутри вовне аналогично). Потому что доступный извне SMB-протокол это, как бы, верх извращения...
Secundo, у вас случайно шлюз не на Atom 2013-2014 гг. выпуска? И сетевые интерфейсы не встроенные ли используются? А то были прецеденты (в собственной практике тоже попался), не зависящие от операционной среды и конфигураций...

nerot · 07.07.2020

oko сказал(а):

Есть две независимые друг от друга сети, соединенные шлюзом. Сеть LAN - простая одноранговая сеть с несколькими серверами, рабочими станциями и некоторым оборудованием. Сеть WAN большая корпоративная многоуровневая доменная сеть.
Пользователи WAN должны подключаться к серверу, который находится в LAN через этот шлюз. Порты, по которым нужно подключение есть в конфиге - 1521, 8080, 445, 3389. Больше от шлюза ничего не требуется, т.е. пользователям LAN в сеть WAN не нужно, а пользователям WAN кроме этого сервера в сети LAN тоже делать нечего.
По железяке завтра скажу, когда на работе буду, но помоему, там Intel Pentium

oko · 07.07.2020

to nerot
Тогда проще всего в вашей корп.сети использовать прямой внутренний IP вашего сервера (192.168.1.1) для доступа. При условии корректной маршрутизации, разумеется. И не понадобится этот огород с PREROUTING...

nerot · 08.07.2020

oko сказал(а):

Не пойдет, У пользователей доменной сети нужно каждому прописывать статический маршрут, т.к. у меня нет доступа к функциям администрирования этой сети, и ко всему прочего у них (пользователей домена) нет прав администратора. Но вашу основную мысль о перемудренности с правилами, и что в этом может быть проблема - уяснил, спасибо за ваши мысли

P.S. Железка на Core 2 Duo E8400

oko · 08.07.2020

to nerot
Корректнее будет им в доменной зоне закрепить DNS-имя за вашим внутренним сервером с указанием на его внутренний IP-адрес. При этом на их дефолтном маршрутизаторе прописать единственный маршрут, что в 192.168.1.0/24 можно попасть через 10.107.131.19. А клиентам уже перенастроить подключение по DNS-имени вместо IP-адреса. Так оно на будущее будет проще при масштабировании...
У меня две сети есть с постоянными терминальными подключениями (клиенты в одной подсети, сервер в другой - шлюз их соединяет между собой). MASQUERADE давал незначительные снижения производительности. При переходе на чистый FORWARD (без участия цепочки nat вообще) сбоев за полгода эксплуатации не наблюдалось...
Кстати, вы обновления какие-либо устанавливали? И параметры, предписанные Red-Book, настраивали?
И еще один вопрос: сеть сконфигурирована через /etc/networking/interfaces или посредством GUI-приложения NetworkManager?

nerot · 09.07.2020

oko сказал(а):

Как я уже говорил, у меня нет доступа к функциям администрирования корпоративной сети, и просто так, по моим хотелкам никто ничего не пропишет, поэтому лепим из того, что имеем.
Все апдейты поставлены по 29.10.2019 включительно. Про Red-Book, это где и чего он напредписывал? Не видел...

oko · 10.07.2020

to nerot
Red book - описание основных механизмов защиты и рекомендации по их настройке. Для АС с гостайной, собственно, настоятельные рекомендации, ага...
Сейчас пролистал для Смоленска 1.5, понял, что под вашу ситуацию вряд ли подходят конфликты с настройками по Red Book...
По установленным апдейтам вроде тоже ничего не должно затрагивать сетевую подсистему...
Короче, пока наиболее вероятным "узким местом", imho, следует считать избыточный обратный NAT...

nerot · 11.07.2020

oko сказал(а):

Спасибо вам за информацию и за ваши мысли. Будем изучать и оптимизировать. Нужно будет попробовать 445 порт убрать из правил, т.к. он с наибольшей вероятностью может давать сбои.

Поиск

Поиск

Странные подвисания "проброшенных" портов

nerot

New member

Вложения

oko

New member

oko

New member

nerot

New member

oko

New member

nerot

New member

oko

New member

nerot

New member

oko

New member

nerot

New member