local proxy arp mikrotik

При настройке VPN-сервера на Mikrotik, могут быть ошибки. Некоторые из них не связаны с очепятками и недостатком знаний. Могут встречаться нелогичные или специфичные для какой-то ситуации ошибки.

Proxy-arp на внутреннем бридже

При подключении по VPN вы можете неприятно удивиться, почему вы можете открыть страницу логина в роутер, 192.168.88.1 (если у вас такой), но не сможете открыть ни один внутренний ресурс. Штука в том, что надо включить proxy-arp на внутреннем интерфейсе, за которым есть нужный вам ресурс. У меня proxy-arp включен на весь bridge-local. Этот параметр позволяет взаимодействовать хостам, находящимся в разных сегментах сети, между друг другом.

Меню Interfaces -> открываете bridge-local, в пункте ARP выбираете proxy-arp.

Глюк default policy на микротик

При абсолютно верных настройках L2TP/IPSec подключения на клиенте (например, Windows 7) и на сервере (Mikrotik), не удается установить VPN-подключение. При этом в лог Mikrotik идет сообщение «failed to pre-process ph2 packet», а на клиенте Windows 7 выходит ошибка 789: попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности. Данная проблема может иметь место на прошивках вплоть до последней стабильной на текущий момент (6.30).

Решение: удалить созданную по умолчанию группу в меню IP — IPSec — Groups, создать новую и указать ее в IP — IPSec — Peers в поле Policy Template Group.

По сообщению Hopy, еще одним решением проблемы с группами может стать выполнение этой команды после пересоздания группы:

ip ipsec peer set 0 policy-template-group=*FFFFFFFF

Возможно, это наследие от старых конфигураций, точного ответа нет, но тем не менее, это вариант. Кстати, возможно по этой причине (и ей подобным) все же стоит выполнять полный сброс устройства перед начальной настройкой. Но требованием это не является, это уж точно.

Ошибки firewall на всех этапах

Ну и не забывайте про то, что в нормальной ситуации при подключении удаленного клиента действуют сразу несколько ограничений, в числе которых брандмауэр клиента, брандмауэр шлюза клиента (или провайдерский прокси), брандмауэр самого микротик (и не только цепочка input — серьезно помешать может цепочка forward), который вы раньше настроили максимально строго, не так ли? Всякие NAT через NAT и траверсом погонять могут. Так что старайтесь всегда разумно и спокойно локализовывать проблему.

пятница, 17 мая 2013 г.

Настройка PPTP в Mikrotik (proxy-arp, gre,1723)

# Включаем ARP-proxy чтобы можно было пинговать машины внутри сети
/interface ethernet
set Local-Port-Name arp=proxy-arp

# Разрешаем локальный dns для пользователей vpn
/ip dns
set allow-remote-requests=yes

# Создаем pool адресов для пользователей vpn
/ip pool
add name=vpn-pool ranges=192.168.0.100-192.168.0.150

# Создаем профиль PPTP сервер
/ppp profile
add ppname=pptp-in local-address=192.168.0.1 remote-address=vpn-pool use-mpls=default use-compression=default use-vj-compression=default use-encryption=required only-one=default change-tcp-mss=yes dns-server=192.168.0.1

# Активируем PPTP сервер
/interface pptp-server server
set enabled=yes max-mtu=1460 max-mru=1460 authentication=chap,mschap1,mschap2 default-profile=pptp-in

# Разрешаем подключаться к PPTP серверу из интернета и разрешаем GRE трафик
(правило должно быть выше последнего запрещаещего)
/ip firewall filter
add chain=input action=accept protocol=tcp in-interface=Inet-Port-Name dst-port=1723
add chain=input action=accept protocol=gre

# Создаем пользовалей vpn
/ppp secret
add name=vpnuser password=password profile=pptp-in

Дано:
— Источник: www.youtube.com/watch?v=cHBkf5UeYIQ
— VPN-линк между двумя 951ми микротиками
— выключенный firewall на обоих тиках

на обоих тиках
— включен proxy-arp на обоих локальных бриджах тика-сервера и тика-клиента
— на каждом тике в свойствах используемого PPP-профиля указан локальный бридж

микротики между собой пингуются, пинги до компов не ходят, хотя в видео пинги есть
— что я сделал лишнего, или не доделал?
— при каких настройках (минимальных) все должно 100% работать?

  • Вопрос задан более трёх лет назад
  • 19584 просмотра

Зачем Вам НАТ между сетями? специально или просто так?)

На клиенте — не понял как скопировать конфиг, на словах:
PPTP-Client, login+pass из сервера, profile=default, use default route=no, allow=pap, chap, mschap1, mschap2; local address=192.168.5.1

на первом микротике

/routing ospf network
add area=backbone network=сетка локалка на первом микротике
add area=backbone network=впн сетка

на втором микротике
/routing ospf network
add area=backbone network=сетка локалка на втором микротике
add area=backbone network=впн сетка

после этого микротики будут знать где какая сетка. а сейчас они у тебя ответы на покеты приходящие из удаленной локалки отправляют не в тунель на дефолтный шлюз.

сделал:
на первом микротике (который сервер)

на втором микротике (который клиент)

@Diman89
1. на первом роутере поднимаете pptp сервер
2. на втором поднимаете pptp клиент
3. на первом роутере прописываете постоянный маршрут к подсети за вторым роутером через pptp-ip-адрес второго роутера
4. на втором роутере прописываете постоянный маршрут к подсети за первым роутером через pptp-ip-адрес первого роутера

p.s. в обоих сетях роутеры являются шлюзами по-умолчанию?

Вкратце такая схема. Вы знаете как эти пункты реализовать?

Выключите masquerade для VPN, потому что он вам не нужен для общения между сетями. Вполне логично, что клиенты не пингуются, т.к. они находятся за NAT.

Например, сеть #1 – 192.168.1.0/24, а сеть #2 – 192.168.2.0/24. Представим ситуацию, что вы делаете пинг с компьютера в сети #1 (192.168.1.2) на компьютер в сети #2 (192.168.2.2). Если очень грубо, то пакет улетает на роутер #1, который смотрит маршрут и отправляет этот пакет на роутер #2, который в свою очередь отправляет его получателю. Да, сейчас все правильно, но есть одно важное но. Т.к. у вас стоит маскарадинг, то компьютер #2 отправляет ответ на свой роутер #2, который в свою очередь из-за masquerdae меняет адрес источника с 192.168.2.2 на 192.168.2.1 и дальше по цепочке к компьютеру в сети #1.Только вот этот компьютер не примет этот пакет, так как он ждет пакета с источником 192.168.2.2, а прилетает ему с адресом 192.168.2.1. Вот где загвоздка и получается.

Решением может быть простое отключение masquerade или можно банально вписать в правило маскарадинга не преобразовывать адрес транзитных пакетов отправленных в соседнюю сеть.

192.168.0.0/16 замените на вашу подсеть

Оцените статью
SoftLast
Добавить комментарий