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

    Проблемы с RDP

    Scheduled Pinned Locked Moved Russian
    27 Posts 6 Posters 2.4k 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.
    • R
      rubic @CrazyMax
      last edited by rubic

      @CrazyMax
      Ну, раз проблема в сети, а не в pfSense, то и говорить собственно не о чем. Заканчивайте переход, и все наладится.
      ЗЫ: его можно было сделать существенно проще вообще-то)

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

        Дык в том то и дело что проблема именно в pfsense. Проблема с RDP возникает именно тогда когда доступ происходит из одной сети в другую.
        Если не сложно, расскажите как это сделать проще?

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

          @CrazyMax
          Проще я бы дал LAN pfSense адрес 10.0.0.1/8 и завел бы Virtual IP 192.168.1.1/24 (или что там у вас было?) на LAN. Это позволило бы избежать 2 карт и роутинга через pfSense трафика от хостов находящихся в одной L2 сети. Предупреждаю - не проверял, но в теории все должно работать

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

            Ага. Ну я как раз перед переходом и думал как лучше. Две сетевушки или одна с VirtIP... видимо как всегда не угадал. :) Лотерея - это не мое :)
            А, если не сложно, можете в двух словах сказать почему в этом случае лучше использовать VirtIP, а не отдельные сетевые?
            Ну и вопрос остался неразгаданным. Почему если трафик идет через две сетевухи RDP отваливается.

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

              @CrazyMax
              Предполагаю, что asymmetric routing, которого pfSense, как всякий stateful firewall не терпит по умолчанию. Тут поведение сервера с двумя адресами просто не ясно и гадать я не буду - нет смысла. Можете найти в pfSense насройку: "Bypass firewall rules for traffic on the same interface" и включить ее - авось что изменится.
              Virtual IP, который отвечает на ARP позволил бы вам избежать 2 карт и роутинга через pfSense трафика, который и так может идти напрямую и соотв. всех проблем с ним

              1 Reply Last reply Reply Quote 1
              • C
                CrazyMax
                last edited by

                Спасибо. Уже перенастроил на VirtIP. Вторую отключил.
                Но в работе проверить не смогу, сегодня выходной, а по VPN и так работало. Уже с понедельника отпишусь по результатам.
                ОГРОМНОЕ спасибо за совет.

                R 2 Replies Last reply Reply Quote 0
                • R
                  rubic @CrazyMax
                  last edited by

                  @CrazyMax какой тип Virtual IP выбрали? (я не хочу отвечать за ваши безумные действия! :))

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

                    @CrazyMax почитал доки, вам подходит тип IP Alias

                    C 1 Reply Last reply Reply Quote 1
                    • C
                      CrazyMax
                      last edited by

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • C
                        CrazyMax @rubic
                        last edited by

                        @rubic Ну я Crazy только в нике, который еще со времен Фидо остался. А так я тихий и спокойный :)
                        Да, этот тип я и использовал.
                        Самое смешное/обидное, что я когда тестировал pfsense, то именно VirtIP я и настраивал (на тестовой машине были всего две сетевухи).
                        Ладно, век живи, век учись, а все равно дурнем помрешь, как говорится :)

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

                          @CrazyMax пишите что там выйдет, я в понедельник постараюсь быть

                          C 1 Reply Last reply Reply Quote 1
                          • C
                            CrazyMax @rubic
                            last edited by

                            @rubic Вот только дошли руки написать. Ношусь по заводу как сайгак, меняю адреса у юзеров....
                            В общем ситуация не поменялась. Связь с RDP по прежнему рвется, если пытаться заходить из одной сети в другую.
                            Вот сегодня перевел уже процентов 95 юзеров и поменял настройки LAN. Теперь сеть 10.0.0.0 основная, а 192.168.1.0 прописана как VitrIP.
                            Ситуация с RDP не поменялась. Отваливается каждые 40-50 секунд. При этом, повторюсь, пинги при отвалах RDP продолжают идти как ни в чем ни бывало.
                            В принципе это уже не важно. Еще день-два и я планирую сеть 192... вообще убрать. Но просто интересен сам факт наличия такой траблы.

                            K R werterW 3 Replies Last reply Reply Quote 0
                            • K
                              Konstanti @CrazyMax
                              last edited by Konstanti

                              @CrazyMax Возможно проблема в ассиметричной маршрутизации между сетями
                              Схематически это выглядит так
                              Проблема в том , что ответные пакеты идут мимо PFSense напрямую к хосту

                              f213043f-b56a-4e39-9eaf-1ce0dca9abe4-image.png

                              Из инета текст
                              Трафик от PC1 до PC2 проходит через pfSense, поскольку он является шлюзом по умолчанию для PC1, однако трафик противоположного направления (PC2 -> PC1)проходит непосредственно от маршрутизатора к PC1. Так как pfSense - брандмауэр с поддержкой состояний, он должен видеть все соединения, чтобы нормально выполнять фильтрацию трафика. В случае ассиметричной маршрутизации, любая работа stateful-брандмауэра закончится отбрасыванием законного трафика, поскольку невозможнодолжным образом сохранить состояние не видя трафика проходящего в обоихнаправлениях. Всегда проверяйте отмечайте флаг Bypass firewall rules для трафика на самом интерфейсе на странице System >> Advanced при сценарии ассиметричноймаршрутизации, дабы воспрепятствовать сбросу законного трафика.

                              C 2 Replies Last reply Reply Quote 0
                              • C
                                CrazyMax @Konstanti
                                last edited by

                                @Konstanti Спасибо за совет, но не помогло. Флаг поставил и даже на всяк случай ребутнул. Не помогло.

                                1 Reply Last reply Reply Quote 0
                                • C
                                  CrazyMax @Konstanti
                                  last edited by

                                  @Konstanti Кстати, проверил вот еще что. Есть IP видеорегистратор и IP камеры. Так вот сейчас проверил, регик в одной сети, камеры в другой. Отвалов нет. Смотрел минут 15, на регике видео идет стабильно со всех камер. Камеры подключается к регику по портам 8000 и 3777...

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

                                    @CrazyMax said in Проблемы с RDP:

                                    Но просто интересен сам факт наличия такой траблы.

                                    Сложно сказать. Тут все зависит от поведения этих multihomed хостов, чего мы не знаем. Мое мнение - забить и доделать начатое. На разбор полетов вы просто потратите время. По идее, при asymmetric routing вы бы вообще соединиться не могли бы, какие уж там 40-50 секунд. Просто tcp handshake бы не прошел. Тут все - гадание на кофейной гуще, мы не знаем то, что вы посчитали не важным и нам не сказали, просто завршите переход на новую сеть и все.

                                    P 1 Reply Last reply Reply Quote 1
                                    • P
                                      pigbrother @rubic
                                      last edited by

                                      @CrazyMax said in Проблемы с RDP:

                                      два LAN смотрящих в разные сети (192.168.1.0 и 10.0.0.0).

                                      10.0.0.0/8? Если да - слишком широкая маска для офиса. Сильно ограничите себя, если появятся филиалы\туннели и т.д

                                      C 1 Reply Last reply Reply Quote 1
                                      • C
                                        CrazyMax @pigbrother
                                        last edited by

                                        @pigbrother Да, 10.0.0.0/8 А в чем будет ограничение? Филиалов у нас нет. ВПН есть, с помощью него к нам подключаются из центрального офиса. OpenVPN поднят на этом же pfsense.

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

                                          @CrazyMax said in Проблемы с RDP:

                                          @pigbrother Да, 10.0.0.0/8 А в чем будет ограничение? Филиалов у нас нет. ВПН есть, с помощью него к нам подключаются из центрального офиса. OpenVPN поднят на этом же pfsense.

                                          Навскидку.
                                          1.Тем, что в филиалах, которые возможно захотите подключить к центральному офису через VPN вы не сможете использовать сеть 10
                                          2.Вы не сможете использовать сеть 10 для адресации туннелей\клиентов OpenVpn в режиме tun (tun весьма удобен\популярен)
                                          3. Иногда провайдеры мобильного и не только интернета выдают адрес из сети 10/8.
                                          И т.п.
                                          Для офиса достаточно 10/24, для большого - 10/16. Хотя ничто не мешает использовать, например, 10/21
                                          https://www.syslab.ru/ipcalculator

                                          @CrazyMax said in Проблемы с RDP:

                                          Филиалов у нас нет

                                          От их появления никто не застрахован☺
                                          У меня их тоже не было. А сейчас есть.

                                          C 1 Reply Last reply Reply Quote 0
                                          • C
                                            CrazyMax @pigbrother
                                            last edited by CrazyMax

                                            @pigbrother Спасибо за советы, но:

                                            1. В филиале, если он появится используем 192... или 176... Не вижу проблемы
                                            2. У меня OpenVPN в режиме tun. Использую сеть 192.168.219.0/24 В этом есть какая-то проблема?
                                            3. Согласен, такое бывает. Но тогда никто не застрахован и от провайдера выдающего 192...

                                            Жалко что Вы не прочитали мое второе сообщение, иначе Вы бы не предложили мне сетку 10/24 в замен 192/24. :)
                                            Ну а ссылка на ipcalculator.... ну спасибо что хоть не на азбуку.

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