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

    Странный рутинг

    Russian
    7
    36
    13.2k
    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

      @chawoosh:

      Где вы нашли провайдера, который вам даёт левонетовские адреса?
      Если у вас десятые сети прописаны как /8 или хотя бы как /16, то ничего удивительного.

      Нам корпоративный канал пров предоставляет внутри своей сети (vlan-ом). И да , когда на WAN - Инет, то без NAT-а никуда.
      Просто не стоит однозначно утверждать , что без трансляции адресов невозможно функционирование сетей.
      Мой пример - как частный случай такой возможности.

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

        @werter:

        @chawoosh:

        Где вы нашли провайдера, который вам даёт левонетовские адреса?
        Если у вас десятые сети прописаны как /8 или хотя бы как /16, то ничего удивительного.

        Нам корпоративный канал пров предоставляет внутри своей сети (vlan-ом). И да , когда на WAN - Инет, то без NAT-а никуда.
        Просто не стоит однозначно утверждать , что без трансляции адресов невозможно функционирование сетей.
        Мой пример - как частный случай такой возможности.

        У нас провайдер с белым адресом канал выделяет, а маршрутизация с помощью BGP сделана без NATа. VLAN-ов нет, по крайней мере на нашей стороне.
        Одно время на этом канале с успехом работал PFSense с пакетом BGP.

        SquidGuardDoc EN  RU Tutorial
        Localization ru_PFSense

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

          Да, снимаю своё утверждение про NAT, как сказанное в запале. В данном случае NAT'ом изолирован зоопарк внутри вмварного сервера от корпоративной сети.

          У нас провайдер с белым адресом канал выделяет, а маршрутизация с помощью BGP сделана без NATа. VLAN-ов нет, по крайней мере на нашей стороне.
          Одно время на этом канале с успехом работал PFSense с пакетом BGP.

          Если у вас внутри сети - белые адреса (трансляция 1:1), то NAT естественно не нужен. Если левонет - обязан наличествовать, т.к. в И-нете левонет не живёт. BGP занимается маршрутизацией между автономными системами (в основном) и к преобразованию адресов никакого отношения не имеет.

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

            Давайте для начала скриншоты

            1. System -> Routing -> Gateways, Routes и Groups (если не пусто)
            2. Firewall -> Rules по всем вкладкам
            1 Reply Last reply Reply Quote 0
            • C
              chawoosh
              last edited by

              Ну что ж, обнажимся…

              Остальные вкладки пустые


              одна строка дублируется в скриншоте

              Остальное пусто.

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

                В System -> Routing -> Routes заведите маршрут:

                10.8.0.0/24 	GWvpn 	WAN
                

                В Firewall -> Rules -> Floating зайдите в редактор правила, поставьте галку "Disable this rule" и сохраните

                В Firewall -> Rules -> WAN добавьте правило:

                
                        Proto 	Source 	Port 	Destination 	Port 	Gateway
                Pass    ICMP 	* 	 * 	* 	 	* 	*
                
                

                Пробуйте пинговать WAN IP pfSense с из сети 10.8.0.0/24
                Пробуйте пинговать хост в сети 10.8.0.0/24 из сети 192.168.0.0/24

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

                  С этого всё начиналось, правда без ICMP, за ненадобностью. Коннект по TCP к внутреннему сайту не проходил, по причине не прохождения обратных пакетов, точнее, направление их на дефолтный гейт. Пакеты генерируемые внутренними хостами так же уходили туда. Сейчас ситуация следующая (для тех кому лень читать ранние посты):
                  пакеты от внутреннего хоста идут к хостам в VPN (по правилу в "плавающих") и получают ответы, пакеты от хостов из VPN доходят до внутренних хостов, ответные пакеты отправляются на дефолтный гейт.
                  На дефолтном гейте (киске 3825) заведено правило которое отправляет пакеты, адресованные в сеть VPN на сервер VPN, благодаря чему всё стало доступно (плюс некоторые побочные эффекты).

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

                    Кажется у меня больше желания разобраться почему простой маршрут не работает, чем у вас. Понимаю, все кое-как наладилось и не хочется начинать с начала.
                    Если не трудно, прикрепите config.xml (Diagnostics -> Backup/Restore -> Download Configuration), я подниму его в виртуалке. pfSense у вас на "серых" адресах, пароль в конфиге в открытом виде не хранится. Думаю, бояться тут нечего.

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

                      Да в общем без проблем… Меня немного напрягает наличие одинаковых МАС на WAN и LAN интерфейсах, но мне эта машина так и досталась, а тот кто её ставил сюда явно не лазил, чистый юзверь.

                      Расширение .txt убрать, будет маленький архив bz2.

                      config-virt.bz2.txt

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

                        Ну, кажется и мне пришло время признать ошибку. В то время как http://doc.pfsense.org/index.php/2.0_New_Features_and_Changes сообщает нам, что "You can have multiple gateways per interface", на деле это не работает: http://redmine.pfsense.org/issues/651.
                        Думаю, что настройка gateway в свойствах интерфейса перекрывает все, что введено руками в System -> Routing -> Routes.
                        Это не баг, а фича - пишет разработчик. Можно поставить gateway: none, но тогда хосты за pfSense не попадут в интернет. Кое-кто рапортует, что ему помогло отключение NAT. Сам разработчик склоняется к floating rule.
                        Вложение у меня не открылось (ошибка CRC), можно скриншот вашего floating rule?
                        Простейшим выходом из ситуации вижу поднятие tagged vlan между pfSense и Cisco. В pfSense при этом останется интерфейс 192.168.21.xxx на котором и можно будет прописать маршрут в 10.8.0.0/24

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

                          @chawoosh:

                          Вопрос: что за …? На BSD, линуксе и даже винде (!) такие правила работают без проблем.

                          Вы просто плохо представляете насколько винда няшна и ковайна)) Винда, к примеру, может вытянуть из PPP-линка статические маршруты и адреса DNS-серверов, а pfSense - не может.
                          Предполагая, что в топик набежит наш общий друг aleksvolgin, спешу сообщить, что и Mikrotik не может. Не удивительно - это не предусмотрено RFC. Но кому какое дело?
                          Вот и в pfSense разработчик видимо счел ситуацию 2-х gateways на одном интерфейсе статистически незначимой))

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

                            Юмор ситуации в том, что у нас вся сеть побита на VLAN'ы, соответственно сабинтерфейс киски, VPN сервер и pfSense находятся внутри 21й виланы. Но поскольку VLAN - понятие 2-го уровня, она благополучно терминируется на интерфейсе вмварного сервера, который естественно находится на L3. Причём из-за некоторой некомпетентности гл. инженера, который решил сам написать конфиг интерфейса к которому подключен сервер - туда приходит именно тегированный VLAN.

                            Скриншот "плавающего руля" - на предидущей странице, самый первый.
                            Архивчик однако побился при загрузке - скорее потому что его грузили как текст.

                            @rubic:

                            @chawoosh:

                            Вопрос: что за …? На BSD, линуксе и даже винде (!) такие правила работают без проблем.

                            Вы просто плохо представляете насколько винда няшна и ковайна)) Винда, к примеру, может вытянуть из PPP-линка статические маршруты и адреса DNS-серверов, а pfSense - не может.
                            Предполагая, что в топик набежит наш общий друг aleksvolgin, спешу сообщить, что и Mikrotik не может. Не удивительно - это не предусмотрено RFC. Но кому какое дело?
                            Вот и в pfSense разработчик видимо счел ситуацию 2-х gateways на одном интерфейсе статистически незначимой))

                            На самом деле юниксы спокойно получают всё, что им посылает сервер PPP, неоднократно проверено на практике. Насчёт pfSense - не знаю, не пробовал.

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

                              Нужно сделать 22-ой (на деле конечно любой) vlan на le0 и тогда в pfSense можно будет добавить новый интерфейс и назначить его WAN с gateway-ем на Cisco, которую конечно тоже придется настроить. 21-й станет как LAN без gateway и все разрулится.
                              З.Ы. Под скриншотом я имею ввиду свойства правила, не то как оно выглядит в Firewall -> Rules -> Floating
                              З.З.Ы. В том то и дело, что не получают. После установления соединения PPP винда хитро шлет в канал запрос DHCP Inform и получает все, что ей нужно. UNIX-like системы, кроме адаптированных к суровым российским условиям аппаратных роутеров некоторых производителей, этого не умеют.
                              Это прекрасно видно на подключении к домашнему интернет Билайн. После установления сессии L2TP винда получает пару дополнительных адресов DNS-серверов и multicast-маршруты билайновского IPTV. Тот же хваленый Mikrotik не получает ничего, ибо протоколом IPCP это не предусмотрено, а грязных трюков он не умеет и не хочет))

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

                                У меня в сети и так куча VLAN с одним - двумя хостами (для изоляции от любопытных, т.с.), а поскольку от получившейся схемы мне уже отходить не хочется, пусть будет всё как есть.
                                PPtP сервер я поднимал, и сам на него коннектился со своей линуксовой машины, Что творит у себя Би - не знаю, там иногда такие "знатоки" попадаются, что хоть стой хоть падай. Если правильно сконфигурять сервер, он будет спокойно передавать сам всё, что нужно подключившемуся клиенту, причем и PPP и OpenVPN сервера это делают одинаково. И "стандарта" на это нет :)
                                Я например своим юзверям отдаю маршрут только в 21й VLAN, где живут сервера. Моя машина существует во всех VLAN'ах предприятия, для простоты. А сейчас на домашнем компе я могу прописать маршрут в любую VLAN вручную и попасть туда куда нужно без лишних маршрутов в таблицах хостов. Это и есть побочные эффекты решения.

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