Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    NAT, перенаправление трафика на другой узел

    Scheduled Pinned Locked Moved Russian
    15 Posts 5 Posters 7.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • werterW
      werter
      last edited by

      Вставлю свои 5 коп

      Виртуализация (кластер- proxmox умеет от 3-х нод) + pf (+CARP)

      1 Reply Last reply Reply Quote 0
      • P
        pigbrother
        last edited by

        Давно думаю про CARP.
        Спрашивал тут:
        https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
        Спрашивал там:
        https://forum.pfsense.org/index.php?topic=111069.0

        Так и  неясно - возможен ли CARP при PPPOE over Ethernet

        1 Reply Last reply Reply Quote 0
        • D
          dilo
          last edited by

          @Bansardo:

          По поводу безотказности:
          MultiWAN на одной железке решает вопрос с отказом канала
          Конфиг файл PF в прямой доступности + стоящий установленный комп с чистым PF решает вопрос по замене сломавшегося за 1 минуту.
          С одной железкой PF не надо мучатся с заворачиванием и перенаправлением.

          Если хотите перенаправить определенные IP, тогда в фаерволе надо прописать маршрут в Firewall LAN  с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80, Destination IP PF2 и порт также 80. А PF должен сам перебросить 80 порт на прокси, если все в одной подсети.
          А чисто теоретически в разделе Route PF1 создать новый шлюз (IP PF2) и задать в ручную для IP нужных компов, предварительно забив их по MAC в статическую таблицу DHCP, этот шлюз. Тоже должно прокатить.

          По поводу безотказности:
          Описанная ситуация аналогична, только пока отсутствует "мультиван". Просто рядом стоящий pf не простаивает а участвует в экскрементах и сейчас это прокси.

          Разве исходящий порт будет 80? Браузер вроде генерирует исходящий порт из свободно используемых.
          Мысль про маршрут была, но тогда прокси должен работать в прозрачном режиме и перехватывать http и https - что без прямого вмешательства к клиентскому пк не получится из-за добавления сертификата под https.

          Попробовал, результата нет :(
          Немного не понял где именно правило надо и сделал разные варианты.
          firewall->NAT

          firewall->rules->lan

          лог в states

          Вместо 80 порта взял и 443 порт https.

          Предполагаю что правило должно быть в Nat зоне с Source IP c any порт и Destination wan net, redirect ip pf2 с протом 3128, Но почему-то оно не срабатывает :(
          Подскажите что бы Вы сделали если бы это было реализовано на одном PF, может по аналогии найду у себя ошибку :( какбы мне завернуть https трафик на порт прокси :(

          @werter:

          Вставлю свои 5 коп

          Виртуализация (кластер- proxmox умеет от 3-х нод) + pf (+CARP)

          Развёрнута аналогичная система, но даже в такой системе может упасть хранилище и кластер с миграцией будет бесполезен + вторая pf преимущественно используется для тестов и экспериментов, как в данном случае возникла потребность в временной прокси.

          1 Reply Last reply Reply Quote 0
          • D
            dilo
            last edited by

            @pigbrother:

            Давно думаю про CARP.
            Спрашивал тут:
            https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
            Спрашивал там:
            https://forum.pfsense.org/index.php?topic=111069.0

            Так и  неясно - возможен ли CARP при PPPOE over Ethernet

            Судя по теме dsl работает роутер работает стабильно, тогда почему не поднять pppoe на нём, пусть он выдаёт "готовый интернет" - поработает, так сказать, роутером. За dsl стаить свич тогда carp можно легко использовать в обычных для него условиях и не привязываться вообще к технологии ПД.

            1 Reply Last reply Reply Quote 0
            • P
              pigbrother
              last edited by

              @dilo:

              @pigbrother:

              Давно думаю про CARP.
              Спрашивал тут:
              https://forum.pfsense.org/index.php?topic=113152.msg630657#msg630657
              Спрашивал там:
              https://forum.pfsense.org/index.php?topic=111069.0

              Так и  неясно - возможен ли CARP при PPPOE over Ethernet

              Судя по теме dsl работает роутер работает стабильно, тогда почему не поднять pppoe на нём, пусть он выдаёт "готовый интернет" - поработает, так сказать, роутером. За dsl стаить свич тогда carp можно легко использовать в обычных для него условиях и не привязываться вообще к технологии ПД.

              Тогда попадаешь в зависимость от надежности\производительности внешнего устройства, плюс прелести двойного NAT.
              Да и нет у меня DSL. К счастью\сожалению.

              1 Reply Last reply Reply Quote 0
              • ?
                A Former User
                last edited by

                @dilo:

                Разве исходящий порт будет 80? Браузер вроде генерирует исходящий порт из свободно используемых.
                Мысль про маршрут была, но тогда прокси должен работать в прозрачном режиме и перехватывать http и https - что без прямого вмешательства к клиентскому пк не получится из-за добавления сертификата под https.

                Это простите как? На каком тогда прокси работает, если порт генерируется рандомно? HTTP всегда ходило и будет ходить в стандарте по 80 порту. Это общепринятый закон.
                @dilo:

                Вместо 80 порта взял и 443 порт https.

                А шифрование не пугает? Ну добавили, ничего не будет работать, только на лишний порт прокси смотреть будет. У нас в компании не запрещали, а просто поставили контроль трафика, кто гуляет куда не надо, предоставляются распечатки инженером по защите информации шефу на планерке, а тот дрюкает потом. И шефу не скучно и все держатся в тонусе. )
                @dilo:

                Немного не понял где именно правило надо и сделал разные варианты.
                firewall->NAT

                Зачем NAT трогать? У вас он итак Ваш диапазон пускает наружу. Как Вы описали, все находится в одном диапазоне ЛВС. Прочитайте что такое NAT и зачем он нужен, дабы не натворить глупостей.

                Мой Вам совет, переходите на одну железку вместо двух и куча вопросов отпадет сама собой. Не делайте масло масляное.

                1 Reply Last reply Reply Quote 0
                • D
                  dilo
                  last edited by

                  @Bansardo:

                  Это простите как? На каком тогда прокси работает, если порт генерируется рандомно? HTTP всегда ходило и будет ходить в стандарте по 80 порту. Это общепринятый закон.

                  Видимо я не верно понял тот вариант который предложили.
                  "с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80" - как понял имелось ввиду перехватывать пакеты которые исходят с источника где ip пк перепроброски (допустим 192.168.1.5) и портом 80.

                  Барузер формирует пакет данных в котором есть Ip:порт источника и ip:порт назначения. Каждое приложение занимает свой порт на устройстве. Обще принято использовать веб серверу для http 80 порт. Для работы firefox нет стандарта использования порта и поэтому он берёт из свободных. Следовательно браузер firefox будет причиной создания пакета где будет ip:порт_из_свободных в источнике и ip_веб_сайта:80 в назначениях. Пример сайт mail.ru 192.168.1.5:48836 -> 217.69.139.199:80
                  Поэтому меня и смутила информация о "с указанием Source IP ПК для переброски (их лучше вбить алиасом) и портом 80". Возможно не прав так как не могу понять как графический интерфейс pf переведёт в правила фаервола. Видимо и меня не так поняли, Извиняюсь.
                  Кстати наглядный пример хождения пакета на 3-тем скрине. Увы, это скрин после построения правил и видно что перенаправления не было.

                  @Bansardo:

                  А шифрование не пугает? Ну добавили, ничего не будет работать, только на лишний порт прокси смотреть будет. У нас в компании не запрещали, а просто поставили контроль трафика, кто гуляет куда не надо, предоставляются распечатки инженером по защите информации шефу на планерке, а тот дрюкает потом. И шефу не скучно и все держатся в тонусе. )

                  Не пугает. Первоначально идёт передача не шифрованных заголовков что прекрасно логируется проксей и можно узнать на каких сайтах сидел пользователь. Нельзя просмотреть только содержимое, но и это можно сделать через SSL Man In the Middle Filtering, но не исключит физический обход перенаправляемых компьютеров .
                  А Вы не задумывались как инженер собирает логи для контроль трафика? Net Flow? Net Stat? Proxy? В любом случае происходит сбор на отдельной машине. Для более простого и ЧИТАБЕЛЬНОГО отчёта чаще всего используется Прокси где тем или иным способом трафик перенаправляется на сервер.

                  @Bansardo:

                  Зачем NAT трогать? У вас он итак Ваш диапазон пускает наружу. Как Вы описали, все находится в одном диапазоне ЛВС. Прочитайте что такое NAT и зачем он нужен, дабы не натворить глупостей.

                  Я прекрасно представляю работу ната и если вы не заметили на скринах отключаю трансляцию адреса при перенаправлении. Роутеру требуется обрабатывать трафик проходящий сквозь него и обработка таких данных в большинстве случаев происходит в зоне NAT (в веб формах не выделяют отдельно зону FORWARD). Явным и простым примером является проброс портов с wan в lan, прмеров которых явно больше чем в моём случае.

                  Я также проделал предложенный вариант, скрин 2, подскажите верно ли правило и так задумывалось?

                  @Bansardo:

                  Мой Вам совет, переходите на одну железку вместо двух и куча вопросов отпадет сама собой. Не делайте масло масляное.

                  Хорошо, я учту. Но в любом случае я так и не увидел варианта перенаправления трафика с хотя бы на одном железке. Вот какой вариант будет когда мне требуется на одном pf перенаправить направленный в интернет трафик с 443 порта на 3128 порт для логирования в проксе.

                  Заранее спасибо.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dilo
                    last edited by

                    В общем проштудировал вручную Рус и основной раздер форума и нашёл множество аналогичных вопросов (не важно сколько роутеров, задача перенаправить трафик на прозрачный прокси).

                    https://forum.pfsense.org/index.php?topic=120850.0
                    https://forum.pfsense.org/index.php?topic=117946.0
                    https://forum.pfsense.org/index.php?topic=113328.0
                    https://forum.pfsense.org/index.php?topic=69664.msg380825#msg380825
                    https://forum.pfsense.org/index.php?topic=100693.msg561267#msg561267
                    https://forum.pfsense.org/index.php?topic=32661.0
                    https://forum.pfsense.org/index.php?topic=97931.msg545547#msg545547
                    

                    Почти все задачи имеют свои отличия, но все сводят к одному решению в виде переадресации трафика на прокси через пункт NAT:

                    The NAT topic.

                    Assuming your squid is running on 3128 + 3129 ports you can try:
                    Source: any
                    Destination any
                    Dport: 80
                    redirect IP: 192.168.1.12
                    redirect port 3128

                    and
                    Source: any
                    Destination any
                    Dport: 443
                    redirect IP: 192.168.1.12
                    redirect port 3129

                    If this is not working then try with such a NAT rule:
                    Source: any
                    Destination any
                    Dport: 80
                    redirect IP: 127.0.0.1
                    redirect port 3128

                    and

                    Source: any
                    Destination any
                    Dport: 443
                    redirect IP: 127.0.0.1
                    redirect port 3129

                    Увы, в моём случае всё это не подошло. Как выяснилось squid в pfsense имеет весьма скудный конфиг и всегда наравит исправить все мои "ручные" изменения на свои. Был развёрнут свой сервер с "игральными автоматомами" и "кальмаром" который отлично отрабатывал в прозрачном режиме http и https. Также отдельная консольная система позволила крутить на себе iptables в любом понравившемся направлении, в следствии чего заворот трафика с 80 и 443 портов на порты прокси было решено сделать именно на данной системе.
                    Главный вопрос упростился, но также остался, "Как перенаправить направленный на 80 и 443 порты трафик идущий с локальной сети без изменений на адрес прокси сервера?".
                    Задача также решена:
                    В разделе firewall->rules->LAN создал правила

                    Action: pass
                    Interface: LAN
                    Address Family: ipv4
                    Protocol: TCP
                    
                    Source alias: iptoproxy (в аиасах вбит список ip)
                    Source port range: any
                    Destination: any
                    Destination port range: 80
                    
                    Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять) 
                    

                    И

                    Action: pass
                    Interface: LAN
                    Address Family: ipv4
                    Protocol: TCP
                    
                    Source alias: iptoproxy (в аиасах вбит список ip)
                    Source port range: any
                    Destination: any
                    Destination port range: 443
                    
                    Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять) 
                    

                    PF перенаправляет только паркеты направленные на 80 и 443 порт на сервер с прокси. Далее firewall на отдельном сервере заворачивает на требуемые порты прокси.

                    Система отлично отработала неделю, НО руководство всё же решило проксировать всех сотрудников так что всё равно пришлось внедрять wpad и выключать всю эту прозрачность.

                    Оставляю найденые решения, вдруг кому тоже потребуется , но в roadmap pf видно что во всю внедряется прозрачность прокси для https без подмены сертификатов.

                    1 Reply Last reply Reply Quote 0
                    • P
                      PbIXTOP
                      last edited by

                      @dilo:

                      В разделе firewall->rules->LAN создал правила

                      Action: pass
                      Interface: LAN
                      Address Family: ipv4
                      Protocol: TCP
                      
                      Source alias: iptoproxy (в аиасах вбит список ip)
                      Source port range: any
                      Destination: any
                      Destination port range: 80
                      
                      Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять) 
                      

                      И

                      Action: pass
                      Interface: LAN
                      Address Family: ipv4
                      Protocol: TCP
                      
                      Source alias: iptoproxy (в аиасах вбит список ip)
                      Source port range: any
                      Destination: any
                      Destination port range: 443
                      
                      Gateway: Proxy IP (прописывается ip прокси сервера на который требуется перенаправлять) 
                      

                      Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

                      1 Reply Last reply Reply Quote 0
                      • D
                        dilo
                        last edited by

                        @PbIXTOP:

                        Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

                        Возможно, но PF не выдавал ошибки  в логах и уведомлений. Возможно из-за того что он не перепроверял список ip а Аслиасе. Возможно так как proxy-ip считается одним из GW.
                        Напрямую в правиле PF запрещает писать ip, но если его добавить в настройках в список GW то можно выбрать в выпадающем меню.
                        А вообще согласен, выглядит странно, быстрее костыль :( , но лучше не нашёл.

                        1 Reply Last reply Reply Quote 0
                        • P
                          PbIXTOP
                          last edited by

                          @dilo:

                          @PbIXTOP:

                          Очень плохая идея по умолчанию, если Proxy IP входит в подсеть самого клиента, которого pfSense перенаправляет, поскольку просто сработает асимметричная маршрутизация, а pfSense её не любит из коробки.

                          Возможно, но PF не выдавал ошибки  в логах и уведомлений. Возможно из-за того что он не перепроверял список ip а Аслиасе. Возможно так как proxy-ip считается одним из GW.

                          А ошибок не будет в логах. pfSense не обращает внимание на плохо устанавливаемые соединения.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.