[РЕШЕНО] Интернет PPTP VPN из Lan subnet
-
Это не то что я просил :)
-
Это не то что я просил :)
парараметры ван на 2003 сервере - 172,20,3,9/24
tracert до pf без впн’а ббЁа
ўЄ ¬ аиагв Є 172.26.62.5 б ¬ ЄбЁ¬ «мл¬ зЁб«¬ Їал¦Єў 301 <1 ¬б <1 ¬б <1 ¬б 172.20.3.1
2 1 ms <1 ¬б <1 ¬б 10.11.11.10
3 * * * ЏаҐўлиҐ ЁвҐаў «
¦Ё¤ Ёп ¤«п § Їаб .4 * * * ЏаҐўлиҐ ЁвҐаў «
¦Ё¤ Ёп ¤«п § Їаб . -
Вот он нужный маршрут
172.16.0.0 255.240.0.0 172.20.3.1 172.20.3.9 1
почему у тебя уходит на 10.11.11.10?
я бы спросил у провайдера, дело тут 100% не в pfsense -
Подсети на сервере и 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 видит сервер как хост в другом - бардак.
-
Подсети на сервере и 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. а шлюз он та то и шлюз чтобы решать в каком сегменте находится адрес назначения пакета
-
Подсети на сервере и 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
-
Подсети на сервере и 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
ушел читать википедию
думает_про_себя как так без шлюза?
-
ушел читать википедию
думает_про_себя как так без шлюза?
потому что это подсеть
допустим у тебя сетка 192.168.0.0/24
компьютер 192.168.0.1 и 192.168.0.2 будут видеть друг друга без шлюза, только за счет броадкаста, так и тут -
тогда почему при написании статического маршрута фигурирует шлюз?
-
шлюзы нужны для маршрутизации между физически разными сетями.
-
У нас один полковник был на военной кафедре… очень любил повторять "Учите матчасть, товарищи солдаты, учите матчасть".
Применительно к нашему случаю - это база, это нужно знать или скорее даже понимать, потом уже двигаться дальше. -
Подсети на сервере и 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. В чем здесь бардак? Почему подсети должны совпадать? -
У нас один полковник был на военной кафедре… очень любил повторять "Учите матчасть, товарищи солдаты, учите матчасть".
Применительно к нашему случаю - это база, это нужно знать или скорее даже понимать, потом уже двигаться дальше.Видимо отсутствие знания матчасти общая черта вендоадминов.
-
У нас один полковник был на военной кафедре… очень любил повторять "Учите матчасть, товарищи солдаты, учите матчасть".
Применительно к нашему случаю - это база, это нужно знать или скорее даже понимать, потом уже двигаться дальше.Видимо отсутствие знания матчасти общая черта вендоадминов.
В чем вы меня тут хотите уличить я не пойму?! Если есть поводы - обосновывайте. Функция цитирования здесь нормально работает.
-
Я почти уверен, что Евгений написал вот этот пост http://forum.pfsense.org/index.php/topic,22804.msg117767.html#msg117767 не изучив вторую станицу темы. Просто вклинился в разговор, увидев знакомые слова =pfsensе, сервер, пинги=. Не посмотрел роут принт с какого хоста я привел…. И увел тему на военную кафедру
-
Я почти уверен, что Евгений написал вот этот пост http://forum.pfsense.org/index.php/topic,22804.msg117767.html#msg117767 не изучив вторую станицу темы. Просто вклинился в разговор, увидев знакомые слова =pfsensе, сервер, пинги=. Не посмотрел роут принт с какого хоста я привел…. И увел тему на военную кафедру
http://forum.pfsense.org/index.php/topic,22804.msg117764.html#msg117764
-
Подсети на сервере и 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 (в случае без статических маршрутов).
И давай поаккуратнее про Евгениев, вклинивающихся в разговор, только увидев знакомые слова. -
2Eugene, чего-то тут в последнее время много буйных… полнолуние как-никак... эээх
-
-
Оцените эту статью. Шел мимо - наткнулся
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Может быть не совсем по теме, но..