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

    [РЕШЕНО] Интернет PPTP VPN из Lan subnet

    Scheduled Pinned Locked Moved Russian
    63 Posts 6 Posters 31.5k 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.
    • E
      Eugene
      last edited by

      @garald50:

      @Eugene:

      Подсети на сервере и pfSense не совпадают

      172.16.0.0      255.240.0.0       172.20.3.1       172.20.3.9      1

      и

      rl1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
              inet 172.26.62.5 netmask 0xffffff00 broadcast 172.26.62.255</up,broadcast,running,simplex,multicast>

      При таком раскладе сервер должен считать, что pfSense в его сегменте, а pfSense видит сервер как хост в другом - бардак.

      По-моему ты неправ. 172.20.3.1 - провайдерский шлюз для 172.20.3.9. а шлюз он та то и шлюз чтобы решать в каком сегменте находится адрес назначения пакета

      Для того, чтобы из сети 172.16.0.0/12 попасть на 172.26.62.5 никакой шлюз использовать не нужно ибо 172.16.0.0/12 включает все хосты от 172.16.0.1 до 172.31.255.254

      http://ru.doc.pfsense.org

      1 Reply Last reply Reply Quote 0
      • G
        garald50
        last edited by

        @Eugene:

        @garald50:

        @Eugene:

        Подсети на сервере и pfSense не совпадают

        172.16.0.0      255.240.0.0       172.20.3.1       172.20.3.9      1

        и

        rl1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                inet 172.26.62.5 netmask 0xffffff00 broadcast 172.26.62.255</up,broadcast,running,simplex,multicast>

        При таком раскладе сервер должен считать, что pfSense в его сегменте, а pfSense видит сервер как хост в другом - бардак.

        По-моему ты неправ. 172.20.3.1 - провайдерский шлюз для 172.20.3.9. а шлюз он та то и шлюз чтобы решать в каком сегменте находится адрес назначения пакета

        Для того, чтобы из сети 172.16.0.0/12 попасть на 172.26.62.5 никакой шлюз использовать не нужно ибо 172.16.0.0/12 включает все хосты от 172.16.0.1 до 172.31.255.254

        ушел читать википедию

        думает_про_себя как так без шлюза?

        1 Reply Last reply Reply Quote 0
        • Z
          zar0ku1
          last edited by

          @garald50:

          ушел читать википедию

          думает_про_себя как так без шлюза?

          потому что это подсеть
          допустим у тебя сетка 192.168.0.0/24
          компьютер 192.168.0.1 и 192.168.0.2 будут видеть друг друга без шлюза, только за счет броадкаста, так и тут

          закрывайте темы, если ответ на ваш вопрос полон.
          если схема сложная - не поленитесь ее нарисовать

          1 Reply Last reply Reply Quote 0
          • G
            garald50
            last edited by

            тогда почему при написании статического маршрута фигурирует шлюз?

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

              шлюзы нужны для маршрутизации между физически разными сетями.

              http://ru.doc.pfsense.org/

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

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

                http://ru.doc.pfsense.org

                1 Reply Last reply Reply Quote 0
                • G
                  garald50
                  last edited by

                  @Eugene:

                  Подсети на сервере и pfSense не совпадают

                  172.16.0.0      255.240.0.0       172.20.3.1       172.20.3.9      1

                  и

                  rl1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                         inet 172.26.62.5 netmask 0xffffff00 broadcast 172.26.62.255</up,broadcast,running,simplex,multicast>

                  При таком раскладе сервер должен считать, что pfSense в его сегменте, а pfSense видит сервер как хост в другом - бардак.

                  Евгений, объясни пожалуйста в чем здесь бардак?
                  1-й Сервер 2003 находится в сети провайдера по адресу 172.20.3.9. Он пытается достучаться по РДП до 2-го сервера 2003 в сети pfSense, который (pf) в сети провайдера по адресу 172.26.62.5. В чем здесь бардак? Почему подсети должны совпадать?

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

                    @Eugene:

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

                    Видимо отсутствие знания матчасти общая черта вендоадминов.

                    http://ru.doc.pfsense.org/

                    1 Reply Last reply Reply Quote 0
                    • G
                      garald50
                      last edited by

                      @deutsche:

                      @Eugene:

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

                      Видимо отсутствие знания матчасти общая черта вендоадминов.

                      В чем вы меня тут хотите уличить я не пойму?! Если есть поводы - обосновывайте. Функция цитирования здесь нормально работает.

                      1 Reply Last reply Reply Quote 0
                      • G
                        garald50
                        last edited by

                        Я почти уверен, что Евгений написал вот этот пост http://forum.pfsense.org/index.php/topic,22804.msg117767.html#msg117767 не изучив вторую станицу темы.  Просто вклинился в разговор, увидев знакомые слова =pfsensе, сервер, пинги=. Не посмотрел роут принт с какого хоста я привел…. И увел тему на военную кафедру

                        1 Reply Last reply Reply Quote 0
                        • Z
                          zar0ku1
                          last edited by

                          @garald50:

                          Я почти уверен, что Евгений написал вот этот пост http://forum.pfsense.org/index.php/topic,22804.msg117767.html#msg117767 не изучив вторую станицу темы.  Просто вклинился в разговор, увидев знакомые слова =pfsensе, сервер, пинги=. Не посмотрел роут принт с какого хоста я привел…. И увел тему на военную кафедру

                          http://forum.pfsense.org/index.php/topic,22804.msg117764.html#msg117764

                          закрывайте темы, если ответ на ваш вопрос полон.
                          если схема сложная - не поленитесь ее нарисовать

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

                            @garald50:

                            @Eugene:

                            Подсети на сервере и pfSense не совпадают

                            172.16.0.0      255.240.0.0       172.20.3.1       172.20.3.9      1

                            и

                            rl1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                                   inet 172.26.62.5 netmask 0xffffff00 broadcast 172.26.62.255</up,broadcast,running,simplex,multicast>

                            При таком раскладе сервер должен считать, что pfSense в его сегменте, а pfSense видит сервер как хост в другом - бардак.

                            Евгений, объясни пожалуйста в чем здесь бардак?
                            1-й Сервер 2003 находится в сети провайдера по адресу 172.20.3.9. Он пытается достучаться по РДП до 2-го сервера 2003 в сети pfSense, который (pf) в сети провайдера по адресу 172.26.62.5. В чем здесь бардак? Почему подсети должны совпадать?

                            Никто никого ни в чём не обвиняет. Если подсети совпадать не должны, значит они не должны пересекаться (включать одни и те же IP).
                            Вкратце о подсетях. Суть здесь в том, что 172.20.3.9 видит, что 172.26.62.5 принадлежит его подсети, поэтому никогда default gateway использовать не будет, чтобы пытаться его достичь, а вместо этого пошлёт Broadcast ARP пакет "на каком MAC'е висит 172.26.62.5?". Ему по идее 172.26.62.5 должен ответить "о! это мой IP, у меня MAC такой-то если тебе интересно" и 172.20.3.9, получив такой ответ, спокойно заполняет MAC фрэйма и выкладывает его на Ethernet сегмент. Данный фрэйм попадает на сетевые карты всех устройств, подключенных к данному сегменту, но только 172.26.62.5, видя свой MAC-адрес, понимает, что этот пакет адресован ему и обрабатывает его.
                            Теперь что у тебя неправильно - неправильно то, что маски(подсети) у твоих хостов разные и не просто разные, а именно то, что одна подсеть включает в себя другую. Как я уже сказал 172.16.0.0      255.240.0.0 означает, что этой сети принадлежат все IP 172.16.0.1-172.31.255.254. Т.е. 172.20.3.9 никогда не будет использовать default gateway, чтобы достучаться до 172.26.62.5.
                            Теперь взглянем на 172.26.62.5 netmask 0xffffff00 - эта подсеть содержит все IP 172.26.62.1-172.26.62.254, т.е. 172.20.3.9 не принадлежит данной подсети и именно поэтому 172.26.62.5 пошлёт пакет, предназначенный 172.20.3.9, в направлении default gateway (в случае без статических маршрутов).
                            И давай поаккуратнее про Евгениев, вклинивающихся в разговор, только увидев знакомые слова.

                            http://ru.doc.pfsense.org

                            1 Reply Last reply Reply Quote 0
                            • Z
                              zar0ku1
                              last edited by

                              2Eugene, чего-то тут в последнее время много буйных… полнолуние как-никак... эээх

                              закрывайте темы, если ответ на ваш вопрос полон.
                              если схема сложная - не поленитесь ее нарисовать

                              1 Reply Last reply Reply Quote 0
                              • T
                                ToXaNSK
                                last edited by

                                @zar0ku1:

                                2Eugene, чего-то тут в последнее время много буйных… полнолуние как-никак... эээх

                                ;D

                                Say what you mean, mean what you say. (Interstate 60)

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

                                  Оцените эту статью. Шел мимо - наткнулся
                                  http://209.85.135.132/search?q=cache:CAAJz-Tk9gUJ:fiery-fenix.kiev.ua/archives/17-FreeBSD_i_GRE._Proksirovanie_na_odin_VPN_server..html+freebsd+%D0%BD%D0%B5%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE+vpn&cd=4&hl=ru&ct=clnk&gl=ru

                                  Может быть не совсем по теме, но..

                                  SquidGuardDoc EN  RU Tutorial
                                  Localization ru_PFSense

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    garald50
                                    last edited by

                                    Нашел решение.
                                    Вот оно - http://forum.pfsense.org/index.php/topic,18874.msg113638.html#msg113638

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