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

    Failover и Port forward есть несколько вопросов.

    Scheduled Pinned Locked Moved Russian
    14 Posts 3 Posters 5.3k 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.
    • C
      chillivilli
      last edited by

      Уважаемые, подскажите кто сталкивался. Есть пограничный pfsense в качесве шлюза с двумя wan от разных провайдеров. Для каждого из них настроен port forward на одну машину внутри сети, порты пробрасываются все 1-65535. Настроен failover и при падении основного канала исходящий траффик уходит по резервному.
      Вопрос в том, как сделать так, чтобы пока не поднялся резервный канал, проброс портов с него на внутреннию машину не работал? Это нужно сделать для того, чтобы траффик приходящий с нескольких машин в инете, которые определяют доступен или нет сервис на 1 или 2 wan-е  корректно проходил. Сейчас можно посылать пакеты на 1 и 2 ван и с обоих он будет успешно форвардится на внутреннюю машину. Может это и не страшно? пусть все время форвардится? Просто я думаю что могут возникнуть различные проблемы, например если пинговать 2 ван то ответ я получаю с 1 ..что не есть правильно..

      1 Reply Last reply Reply Quote 0
      • E
        Eugene
        last edited by

        @chillivilli:

        если пинговать 2 ван то ответ я получаю с 1 ..что не есть правильно..

        Это странно, второй ван и должен отвечать.

        http://ru.doc.pfsense.org

        1 Reply Last reply Reply Quote 0
        • C
          chillivilli
          last edited by

          Точно должен отвечать со второго? если да буду копать правила. Просто может быть думал по поводу icmp такая ситуация,  а аказалось что нет, и по http запросам отвечает с первого wan..у кого есть настроенный failover вариант с двумя wan, можете рассказать что у вас в NAT прописано?

          1 Reply Last reply Reply Quote 0
          • E
            Eugene
            last edited by

            @chillivilli:

            Точно должен отвечать со второго? если да буду копать правила. Просто может быть думал по поводу icmp такая ситуация,  а аказалось что нет, и по http запросам отвечает с первого wan..у кого есть настроенный failover вариант с двумя wan, можете рассказать что у вас в NAT прописано?

            Здесь, ни правила, ни нат не играют никакой роли. На обоих WAN-интерфейсах есть Default Gateway?

            http://ru.doc.pfsense.org

            1 Reply Last reply Reply Quote 0
            • C
              chillivilli
              last edited by

              Да, у каждого вана свой Дефаулт Гейтвей

              1 Reply Last reply Reply Quote 0
              • E
                Eugene
                last edited by

                Можно tcpdump с обоих интерфейсов для пинга на OPT интерфейс? Хочу посмотреть, как приходит по одному, уходит по другому.

                http://ru.doc.pfsense.org

                1 Reply Last reply Reply Quote 0
                • R
                  rubic
                  last edited by

                  Может из-за этого?

                  …
                  Outbound traffic to the Internet

                  All services running locally on pfSense will strictly obey the system's routing table. This means they go out the primary WAN unless you have static routes defined that match the traffic. This only applies to services which initiate connections to the Internet, such as the DNS forwarder, and several packages such as squid.
                  …

                  По крайней мере у меня тоже так. Есть хост в DMZ-LAN с белым IP выданным провайдером подключенным к OPT-WAN. Соответственно, и ходят снаружи на этот хост все через OPT. Но! Если я извне сделаю до него traceroute, то он покажет, что маршрут прошел через WAN т.к. на предпоследнем хопе pfsense генерит ответ destination unreachable от себя, и идет этот ответ через WAN. С провайдером выясняли в свое время почему все так ходит.

                  1 Reply Last reply Reply Quote 0
                  • C
                    chillivilli
                    last edited by

                    прошу прощения. но я ошибся.. прсото в тспдампе и на одном и на другом инт-йсе вместо соответсвующего ип адреса всегда писалось имя хоста самого пфсенса, что меня запутало при беглом анализе. При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.  Это верно как для самого пфсенса так и для портов прокинутых на внутренние машины. В том числе когда с двух внешних ип адресов прокидывается один и тот же порт на одну внутреннюю машину.

                    1 Reply Last reply Reply Quote 0
                    • R
                      rubic
                      last edited by

                      @chillivilli:

                      При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.

                      Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.

                      1 Reply Last reply Reply Quote 0
                      • E
                        Eugene
                        last edited by

                        @rubic:

                        @chillivilli:

                        При более внимательном изучении выяснилось, что на какой ип пришел пакет icmp запроса, с такого интерфейса и ипа уходит ответ.

                        Понятно, значит для пинга заводится state. А с traceroute все сложнее, там же просто UDP пакет прилетает на порт > 30000. Вот и пойми что кто-то маршрут трассирует… Еще раз сейчас проверил, все так как я писал. Так что имейте ввиду.

                        Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.

                        http://ru.doc.pfsense.org

                        1 Reply Last reply Reply Quote 0
                        • R
                          rubic
                          last edited by

                          @Evgeny:

                          Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.

                          Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
                          на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
                          Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
                          Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
                          в точности мой сетап, все так и осталось загадкой…

                          1 Reply Last reply Reply Quote 0
                          • E
                            Eugene
                            last edited by

                            @rubic:

                            @Evgeny:

                            Вообще говоря, pfSense'у должно быть фиолетово (до некоторой степени) - хоть UDP, хоть ICMP.

                            Думаю, не в моем случае. Единственное объяснение, которое я вижу, заключается в том, что:
                            на OPT-WAN с удаленного хоста от traceroute приходит UDP пакет с TTL=1 и назначением = хост в DMZ, (пусть заводится state: udp remote host:port -> DMZ host:port), но TTL обнуляется и пакет отбрасывается, после чего pfsense отправляет ICMP type=3 удаленному хосту.
                            Так вот, по какой-то причине (может потому, что state убивается вместе с пакетом, или потому, что pfsense игнорирует этот state, считая, что он описывает общение удаленного хоста с хостом в DMZ и к самому pfsense не относится) этот ICMP улетает не с OPT-WAN, а по дефолтному маршруту, т.е. с WAN. И в выводе traceroute мы видим WAN, хотя не видим провайдерского шлюза WAN (напротив видим шлюз OPT-WAN).
                            Вот парень мучался пару лет назад: http://forum.pfsense.org/index.php/topic,9171.0.html
                            в точности мой сетап, все так и осталось загадкой…

                            Да, похоже на правду. Суть похоже в том, что ICMP-reply, который отсылается никаким образом не связан с

                            пусть заводится state: udp remote host:port -> DMZ host:port

                            и посему шлётся согласно таблицы маршрутов. Попробуй на pfSense создай static route на твой удалённый хост через OPT-WAN, должно правильно показать маршрут.

                            http://ru.doc.pfsense.org

                            1 Reply Last reply Reply Quote 0
                            • R
                              rubic
                              last edited by

                              Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))

                              1 Reply Last reply Reply Quote 0
                              • E
                                Eugene
                                last edited by

                                @rubic:

                                Да, конечно, с маршрутом все показывает правильно. Как ты понимаешь, это не выход из положения. Просто будем иметь ввиду, что есть у pfsense такая фича))

                                Согласен, но по крайней мере - есть логичное объяснение -)))

                                http://ru.doc.pfsense.org

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