Как объединить PPTP-server и PPTP-client в единую сеть на MikroTik??

Question

[Pan Propan]

В общем дело такое, первый микротик в офисе с белым айпи, второй в филиале с динамическим ай-пи адресом. На микротике офисном поднят PPTP-сервер, со второго микротика цепляюсь PPTP-клиентом к первому Микротику. Вопрос как сделать так, чтоб пользователи LAN второго микротика попадали в бридж первого?

Answer 1

[Клёвый Админ]

Как как? Порассуждать, понять что PPTP это у нас L3 туннель, а значит сделать единый L2 домен с его помощью нельзя, а значит нужно построить EoIP туннель поверх существующего соединения и включить этот EoIP туннель в бриджи с локальной сетью с обоих сторон.

Но немой вопрос "нахрена?" всё же остаётся в воздухе...

Comments

[Pan Propan]

Но немой вопрос "нахрена?" всё же остаётся в воздухе...
_____________________________________________________________
Хотя бы для того, чтоб на каждом клиенте не прописывать, pptp соединение каждый раз.

[Клёвый Админ]

Нариман Алимурадов: нахрена бридж, то? Просто поднять отдельную сеть, dhcp и маршрутизацию - это типа вариант для слабаков? Гонять по нестабильному интернет каналу весь ваш l2 трафик - это так то лютый костыль!

[Клёвый Админ]

Если проще и подробнее - я понимаю о чём вы говорите, вам нужно связать офис и компы в другом офисе. И понятно, что настраивать соединение многие к одному - сложно и плохо. Но, в том вариаент, что вы сейчас реализуете, вы пускаете l2 трафик по pptp туннелю плюс вы оставляете сеть полностью зависимой от работоспособности головы и туннеля. Наиболее правильное решение:
1. В каждом офисе свой dhcp сервер и своя ip сеть
2. Между офисами туннель со своей транзитной (небольшой) сетью
3. Между офисами маршруты через транзитную сеть.

[Pan Propan]

Евгений Быченко: как то так??
pptpclient.sourceforge.net/routing.phtml#client-to-lan

[Pan Propan]

Я наверное не совсем правильно сформулировал вопрос.

Фактически связывать нужно компы филиала с 1с сервером офиса. То есть пускать их в бридж не обязательно, как минимум хотя бы чтоб пинг шел до серверов.

[Клёвый Админ]

Нариман Алимурадов: А у вас прям через интернет будут COM соединения ходить? Плохая затея. Или всё же там на самом деле терминальный сервер и RDP сессии?

В общем, в любом случае нужно делать грамотную маршрутизацию или хоть какую-то маршрутизацию, а не просто соединение PTP.

[Pan Propan]

Евгений Быченко: предполагается что COM будут ходить через инет. Чем эта идея плоха??

Терминалку не планируем поднимать. Клиенты будут по тонкому клиенту коннектиться. Маршрутизацию разумеется настраивать буду.

[Клёвый Админ]

Нариман Алимурадов: ком использует кучу портов, а значит ваш сервер обречён торчать наружу всеми этими портами. Так же он не имеет как такового контроля доставки или терпимости к долгому коннекту. Если терминал не планируется используйте публикацию http. (это я вам как админ 1к баз один эс и как внедренец 1с фреш говорю)

[Pan Propan]

Евгений Быченко: а по скорости и стабильности я не много потеряю??? Используя http вместо vpn-тунеля

[Клёвый Админ]

Нариман Алимурадов: по скорости в сравнении с COM выиграете, по стабильности только выиграете точно. А вот про совместимость с вашей конфой - это нужно проверить. Не каждая база подходит для веб публикации. Сделайте копию и через конфигуратор "Администрирование - Публикация"

[Pan Propan]

Евгений Быченко: конфа последняя ут11, она уж точно поддерживает публикацию http

[Клёвый Админ]

Нариман Алимурадов: если она ещё при этом и на поддержке - то публикация - странно что ещё не используете для удалённых офисов.

***и да используйте apache, а не iis.

[Pan Propan]

Евгений Быченко: а причем тут на поддержке или нет?? Не совсем понятно.

кроме того не будет ли фронткассира тупить при загрузке по http 7-8к номенклатуры?

[Клёвый Админ]

Нариман Алимурадов: поддержка гарантирует что все формы будут корректно работать через http. Если её нет - нужно просто всё протестировать, перед публикацией продакшина. Работа через http в целом практически ничем не отличается от прямого подключения, т.к. по сути протокол просто проксирует запросы к серверу.
А вот совместимость кассового оборудования лучше тестировать отдельно. (я всё же больше по Бухгалтерии чем про Торговлю)

Answer 2

[Pan Propan]

На данной схеме объясните пожалуйста, зачему RemoteOffice несколько интерфейсов 192.168.88.0/24 (HommeOfiice), 10.0.103.1/24 (FromeRemoteOffice) и 10.150.2.1/24 (LocalHommeOffice). Зачем столько интерфейсов ??
И интерфейсы ли это?

Comments

[Клёвый Админ]

Итак, смотри. Вот у тебя сетка, на ней есть:
1. Два ПК - по одному в каждом офисе. Один с адресом 10.150.1.1 и маской 255.255.255.0 второй 10.150.2.1 и аналогичной маской
2. Дальше в каждом офисе по шлюзу
2.1 Для Удалённого офиса шлюз имеет адрес 10.150.1.254 и маску 255.255.255.0 для локальной сети. А так же адрес 192.168.81.1 и маску 255.255.255.0 для выхода в интернет.
2.2 Для Домашнего офиса шлюз имеет адрес 10.150.2.254 и маску 255.255.255.0 для локальной сети. А так же адрес 192.168.80.1 и маску 255.255.255.0 для выхода в интернет.
Как видно из схемы, просто имея такую адресацию компьютеры не смогут друг друга достичь и трафик между ними ходить не будет.

Потому поверх публичной сети построен PPTP туннель имеющий транзитную адресацию, для Удалённого офиса конец туннеля имеет адрес 10.0.103.2, для домашнего офиса туннель имеет адрес 10.0.103.1 и маску 255.255.255.0 - интерфейс этот виртуальный, физически его, естественно нет. Так же адресация на нём может быть в принципе любой (не пересекающейся с публичными и локальными сетями - по желанию и степени костылезации).

Дальше для каждого шлюза настроен маршрут вида
%УДАЛЁННАЯ_СЕТЬ% %МАСКА УДАЛЁННОЙ_СЕТИ% gateway = %АДРЕС_ПРОТИВОПОЛОЖНОЙ_СТОРОНЫ_ТУННЕЛЯ%
Который для данной сети не указан (а зря).

[Pan Propan]

Евгений Быченко: спасибо Вам Евгений за то что на пальцах объяснили. Но зачем в этой схеме To_internet 192.168.80.0/24 и To_internet 192.168.81.0/24

[Клёвый Админ]

Нариман Алимурадов: так это же провайдеры так схематично отмечены. Если бы их не было - не было бы интернета на точках.

[Pan Propan]

Машрут для схемы кстати указан тут
https://www.mikrotik.com/testdocs/ros/3.0/vpn/pptp.php

[Pan Propan]

Евгений Быченко: Евгений подскажите пожалуйста, при создании PPP-secret для чего нужный поля Local-Adres и Remote-Adress. Имеет ли смысл их указывать?? Дело в том что я создаю маршрут и независимо от того какие значения в этих полях Ping между филиалами есть.

[Клёвый Админ]

Нариман Алимурадов: У вас какая версия RouterOS? неужели третья? Если нет, то необходимо читать актуальную документацию расположенную в вики wiki.mikrotik.com/wiki/Manual:TOC
Хорошо бы подкреплять ваши вопросы более развёрнутыми фактами - например скриншотами или примерами маршрутов. Погадав на кофейной гуще делаю вывод, что не зависимо от задаваемых вами параметров VPN таки работает как нужно =)

[Pan Propan]

Евгений Быченко: версия клиентского микротика 5.6, оффисного 6.26.
https://yadi.sk/i/xEbVv5ABg9vh6

https://yadi.sk/i/2wVmlqnkg9vxD

[Клёвый Админ]

Нариман Алимурадов: у вас в маршруте указывается (судя по скрину) интерфейс, и это будет прекрасно работать с pptp (так как там нет по сути сети, там просто вторая сторона туннеля в которую можно просто слать фреймы).

[Pan Propan]

Евгений Быченко: в таком случае мне нужно указывать Local и Remote Adress??

[Клёвый Админ]

Нариман Алимурадов: как хотите =) Можно не указывать, но задать отдельно через соответствующую таблицу ip - address.

[Pan Propan]

Евгений Быченко: убрал Remote и Local Adress, добавил Ip-Adress ping пропал))

вывол Local и Remote обязательны??

[Клёвый Админ]

Нариман Алимурадов: адреса на концах туннеля обязательны. Как вы их задаёте ваше дело, можно через secret, можно через настройку адресов.
Нариман, читайте документацию, анализируйте её самостоятельно. Тостер служит для решения сложных вопросов, а не для консультации на каждый чих.

[Pan Propan]

Евгений Быченко:
Вам спасибо за помощь. Ушел курить доки.