Для бизнеса Частным клиентам Удалённая помощь Выезд специалиста Цены Кейсы Статьи Оставить заявку Контакты
MikroTik · сети3 мин чтения

Почему два офиса через MikroTik и L2TP видят друг друга только в одну сторону

Односторонняя доступность между офисами почти всегда требует проверки не одного туннеля, а всей цепочки: адресации, маршрутов, firewall и NAT.

Ситуация выглядит парадоксально: между двумя офисами поднят L2TP-туннель, из офиса А ресурсы офиса Б доступны, а из офиса Б в офис А — нет. Сам туннель при этом может быть активен, адреса на его концах выданы, а ping до маршрутизатора проходить.

Причина обычно находится не в одной «волшебной галочке». L2TP создаёт транспорт между двумя точками, но доступ между локальными сетями дополнительно зависит от маршрутизации, правил firewall, NAT и корректной адресации.

1. Сначала проверяем адресацию и маршруты

У офисов должны быть разные локальные подсети. Если с обеих сторон используется, например, одинаковая сеть 192.168.1.0/24, маршрутизатор не сможет однозначно понять, куда отправлять пакет. При разных подсетях на каждом MikroTik должен существовать маршрут к удалённой локальной сети через туннель.

Полезно идти от простого к сложному: проверить доступность адреса второго конца туннеля, затем адрес интерфейса маршрутизатора в удалённой LAN и только после этого — конкретного компьютера или сервера.

2. Firewall может пропускать трафик только в одном направлении

Даже при правильных маршрутах пакет может остановиться в цепочке forward. Частая причина — правила создавались для одного направления или стоят ниже общего запрещающего правила. Важен не только текст правила, но и его порядок, счётчики срабатываний и фактические source/destination сети.

На рабочем маршрутизаторе лучше не «разрешать всё для проверки» без понимания последствий. Безопаснее временно включить логирование на конкретное правило или добавить узкое диагностическое разрешение для нужных подсетей.

3. Проверяем NAT

Для обычного доступа между двумя корпоративными подсетями трансляция адресов чаще всего не нужна. Но слишком широкое правило masquerade может захватить трафик, который должен идти между офисами с исходными адресами. Из-за этого обратный маршрут или правила доступа начинают работать не так, как ожидалось.

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

4. Не забываем про конечные устройства

Если маршрутизатор удалённого офиса отвечает, а конкретный компьютер — нет, проблема уже может быть не в L2TP. Локальный firewall Windows, профиль сети, шлюз устройства или политика безопасности способны блокировать входящий трафик из другой подсети.

Как я диагностирую такую проблему

  • фиксирую схему адресации обеих площадок;
  • проверяю состояние туннеля и маршруты в обе стороны;
  • смотрю прохождение пакета по firewall и NAT;
  • проверяю обратный маршрут;
  • после маршрутизаторов перехожу к конкретным рабочим станциям и сервисам.

Такой случай был и в моей практике: два офиса через MikroTik/L2TP имели одностороннюю связность. После последовательной проверки конфигурации удалось восстановить полноценный доступ между сетями.

Если нужна диагностика похожей схемы, можно посмотреть услугу настройки MikroTik и офисных сетей или удалённого доступа к офисной сети.

FROLOV.IT

Нужна помощь с похожей задачей?

Опиши ситуацию — скажу, можно ли решить удалённо или нужен выезд.

ПозвонитьTelegramЗаявка