Проброс порта в другой PFsens
-
@tararashka
Добрый вечер
А в чем суть проблемы ?
Пробрасывается порт , а потом уже маршрутизаторы на основе OSPF сами решат, каким маршрутом пойдет пакет
По таблице состояний обратно пакет пойдет тем же маршрутом , что и пришел .
Или я чего-то недопонял ? Речь идет о каком НАТе ? Исходящем или .... ? -
@konstanti
нужно чтоб телефоны из интернета по активсинку получали почту.
в нат правиле дестанейшен указан адрес и порт сервера за пфсенсом С. создается автоматическое правило в фаерволе для входящего трафика. если посмотреть что по этому правилу пролетает в логе то увидим попытки подключений со статусом
CLOSED:SYN_SENT
Фаервол между шлюзам сейчас разрешает все. Из лан сетей всех шлюзов можно достучатся до сервера.
Если делать проверку порта 44 на шлюзе А и WAN интерфейса до локального адреса сервера, то получаем его недоступность. Если это же делать с лан или тунельных интерфейсов то проверка проходит успешно. -
@tararashka
Мой Вам совет ,
начните с packet capture
Т е начинаем с lan интерфейса маршрутизатора А - ушел пакет или нет , если ушел , то в каком виде , возможно неверно настроен проброс порта, и пакет уходит не на тот порт сервера , который нужен
и так по всей цепочке A->C в первую очередь ( потому что пакет все-таки пойдет по этому маршруту с высокой степенью вероятности )
Дальше интерфейс WAN С - смотрим есть/нет прием/ответ на пакет .
Lan C есть ли ответ на пакет
Ищем то место , где пакеты теряются
А вот потом уже , можно будет понимать , что и как -
@tararashka
Или , как вариант , сделайте правило Nat outbound для 44 порта на интерфейсах Lan гейтвея A - тогда по сети к серверу будут бегать только пакеты с адресом источника из внутренней сети . И проверьте , будет этот вариант работать или нет -
@Konstanti
пакет из интернета через WAN шлюза А долетает успешно натируемый (почтовик получает пакет с интернет адресом телефона) до сервера и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона.
Потому что на шлюзе А есть только входящие пакеты от телефона.Как объяснить серверу что его нужно пульнуть обратно на шлюз А? я так понял что Nat outbound только для подсетей. а стандартный Nat Port Forward с лан интрефеса и адреса сервера на адрес шлюза А результата не дает
-
@tararashka
Те Вы тактично умолчали , что есть еще один шлюз ????? Используйте NAT Outbound на гейтвее А для порта 44 ( интерфейсы Lan ) и будет Вам счастье . Тогда почтовик будет пулять пакеты обратно в ту сеть , откуда они пришли.те схема будет такой ( лень писать пришлю скрин со своих настроек IPtables , тут все так же )
Первая строка - проброс
Вторая - исходящий нат на внутреннем интерфейсе -
@konstanti said in Проброс порта в другой PFsens:
лю скрин со своих настроек IPtables , тут все так же )
я вроде даже картинку приложил. там все шлюзы через которые может пойти трафик от белого адреса до почтового сервера. Если не затруднит ткните носом в мануал по исходящему нату. я рыл в эту сторону, но или уже совсем дурак или что то от усталости со мной происходит.
верно ли я понимаю что мне нужно указать в исходящем нате в Source адрес сервреа/32 (адресом сервера)? и в Destination локальный адрез шлюза А/32 -
@tararashka
и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона. - по-другому я бы такой текст не смог бы понять , кроме как что есть еще один гейтвей у почтовика , куда он и выпуливает пакеты для внешних сетей .
По таблицам состояний этот пакет должен вернуться к А без проблем. Если только у С нет второго выхода в интернет и связки С-А и B-C - не виртуальные каналы
-
@konstanti said in Проброс порта в другой PFsens:
и тот его выпуливает видимо по дефолтгетевую на тот самый интернет адрес телефона
может не так выразился. у для почтовика pfsense С является шлюзом по умолчанию, у которого тоже есть выход в интернет без белого адреса. куда все и улетает.
что то магия не происходит. Огромно спасибо. Что то в голове стало укладываться. завтра продолжу
-
@tararashka
А канал c-a и с-b виртуальный ?????????По таблицам состояний этот пакет должен вернуться к А без проблем. Если только у С нет второго выхода в интернет и связки С-А и B-C - не виртуальные каналы - такая схема без исходящего нат и не будет работать .
Все надо мониторить tcpdump-ом
-
@konstanti
С-А С-В А-В это Овпн тунели пир ту пир. которые объявлены в OSPF. с локальных интервейсов все маршруты работают. У всех шлюзов есть свой выход в интернет.
WAN A-C- (Почтовый сервер) пакет пролетает судя по Packet Capture и почтовик его отдает на адрес телефона.
-
@tararashka
Итак , могу диагноз поставить
при такой конфигурации маршрутA->C->Сервер->C->A при внешнем адресе работать не БУДЕТ
Тоже самое со схемой через B
Варианты решения
1 если почтовику не важен внешний IP - то NAT OUTBOUND на А ( на обоих OPENVPN интерфейсах)2 DDNS на роутере С ( если важно знать внешний IP) и доступ через C напрямую
Если что-то не так , используйте Packet Capture
На выходе с А ( интерф Openvpn) Вы должны увидеть
IP openvpn интерф ( src) -> ip почтовика (dst) -
@konstanti
я наверное задам глупый вопрос.
почему NAT OUTBOUND делать роутере на А? задача именно в том чтоб почтовик выходил через адрес роутера А.
связка почтовик <> роутер С имеет склонность к миграции. и нужен механизм чтоб не зависимо от место положения почта продолжала работать через ip роутера Асобественно к глупому вопросу. мне NAT OUTBOUND нужно делать разве не на роутере С? где красные стрелки? ведь именно там пакет улетает не ту сторону.
Сейчас пакет летит так. Причем входящий пакет видно и на ovpn A-C со стороны рутера С и на порту WAN C в Packet Capture
в конкретно данном случае от WAN C я мог бы отказаться, но у меня нет уверенности что через пол года в нем не появится необходимость. Хотелось бы собрать уже готовую рабочую среду.
на самом деле схема включения мне кажется достаточно стантдартная для средних компаний, а решений и мануалов я как то я не нашел на эту тему..
-
@tararashka
Про вариант С ничего сказать не могу , не проверял . Схема с вариантом А рабочая (NAT OUTBOUND для OpenVPN интерфейсов A). Как ее организовать присылал картинку , только вместо Lan указываете нужный интерфейс Openvpn ( делается это в раздел Manual outbound NAT - тут создается это правило .)
И все будет работать -мой почтовик именно так и работает
Посмотрите настройки IPTables
(DNAT - проброс, SNAT - NAT OUTBOUND)
внешн клиент ->wan (проброс к 1.230)->nat outbound 10.10.100.2->почтовик
обратно
почтовик->10.10.100.2->wan->внешн клиентПример получения письма (если смотреть Ваш вариант - роутер А WAN интерфейс)
17.58.63.184.43701 > 37.153.XXX.XXX.smtp: Flags [S],
37.153.XXX.XXX.smtp > 17.58.63.184.43701: Flags [S.],Роутер А (Openvpn интерфейс)
10.10.100.2.43701 > 192.168.1.230.25: Flags [S],
192.168.1.230.25 > 10.10.100.2.43701: Flags [S.],Роутер С (lan интерфейс)
10.10.100.2.43701 > 192.168.1.230.25: Flags [S],
192.168.1.230.25 > 10.10.100.2.43701: Flags [S.], -
@tararashka а интересный, чёрт возьми, "крокодил" получается...
А вот если пакеты ещё и через B перекидывать надо? WAN, я так понимаю там есть, что мешает резерв сделать?@tararashka said in Проброс порта в другой PFsens:
на самом деле схема включения мне кажется достаточно стантдартная для средних компаний, а решений и мануалов я как то я не нашел на эту тему..
Вот и я про то же, вроде кругом типовые задачи, а как копнешь - так и тупик. Насколько раздули тему, когда надо было офисы связать через OpenVPN. А ложка-то оказалось, что надо всего-лишь OpenVPN самому себе обратку дать.
