Несколько тунней IPSEC GRE + OSPF + NAT

Тема в разделе "Маршрутизация", создана пользователем Max, 29 окт 2017.

  1. Max

    Max Участник

    Моё почтение.
    Есть такая сеть

    Plan.jpg


    2 центральные точки - Office и Cloud
    Соединены между собой GRE туннелем (забыл на схеме нарисовать).
    Из каждого подразделения поднято 2 туннеля по одному в Office и Cloud. В перспективе добавление резервного провайдера в Office и поднятие второго туннеля. Туннели подняты в транспортном режим - добавление IPsec Secret в настройках GRE интерфейса.
    Между всем точками запущен OSPF.

    Есть несколько вопросов.

    1 OSPF
    Из одного подразделения в другое можно попасть 2 маршрутами - через Office или Cloud. Оба имеют одинаковую дистанцию. Периодически трафик в одну сторону идёт по одному маршруту, а обратно по другому. Ping не проходит. Интерфейсы в OSPF динамические. Если сделать интерфейс статическим и увеличить значение Cost ситуация исправляется. Но появляется другая проблема. На Cloud, где значение Cost выше трафик начинает ходить через Office, а не напрямую. Задача сделать так, чтобы подразделения бегали между собой через Office, а на Cloud напрямую.


    2 NAT
    Между сетями настроен NAT.
    Для примера между Home и Cloud
    Cloud
    chain=srcnat action=accept src-address=172.16.0.0/24 dst-address=172.16.100.0/24
    Home
    chain=srcnat action=accept src-address=172.16.100.0/24 dst-address=172.16.0.0/24

    Ping не проходит. Отключаешь виндовый firewall (где разрешено только из локальной подсети) и работает. В чём может быть проблема?
     
  2. Max

    Max Участник

    Добавлял шифрование IPSec через политики, отключил IPSec и оставил только GRE туннели, обновил до 6.40.5.
    Не работает NAT хоть стреляйся.

    Что я делаю неправильно?
     
  3. Илья Князев

    Илья Князев Администратор Команда форума

    Не грохайте invalid на forward в Firewall, по крайней миере между туннельными интерфейсами.

    Рассчитайте косты чтобы суммарный кост филиал-офис-филиал был дешевле чем филиал-клауд-филиал.
    Например ставите на офисные туннели во всех роутерах кост 7, на Клауд 10. Тогда на Клауд он пойдет напрямую т.к. 10<(7+7) а в другое подразделение через офис т.к. (7+7)<(10+10)

    Где-то мне попадалось, что винда проверяет MAC-адреса. В любом случае правильнее конфигурить виновный файрволл.
     
  4. Max

    Max Участник

    Создать Interface List, добавить в него туннельные интерфейсы и в firewall, в правиле invalid forward исключить этот Interface List?

    С костами попробую, спасибо.

    Задолбаешься кинфигурить виндовый firewall на сотне машин в 10 городах. Да и некоторое сетевое железо пускает только из локальной сети. Например роутер TP-Link, переведённый в режим точки доступа.
    Из локалки пускает, из офиса нет.
     
  5. да можно так.
     
  6. Max

    Max Участник

    И всё же почему не работает NAT?
    Принтер в филиале тоже не пингуется и не пускает в web морду из других сетей
     
  7. дайте tracert до клиента
     
  8. dimugric

    dimugric Новый участник

    Коллеги, прошу прощения, но дабы не плодить тем хотел бы задать вопрос, связанный с использованием gre у спикера.
    GRE устанавливает доверительные отношения, если прописать адреса точек на противоположных сторонах, но в качестве бреда, с помощью понимания технологий и спуфинга можно инициировать подлог IP. Каким образом в этом случае можно защитить GRE от таких подлогов? Ведь даже паролем не закрывается туннель.Спасибо
     
  9. Max

    Max Участник

    Это до ПК
    C:\Users\Admin>tracert 172.16.3.241
    Трассировка маршрута к 172.16.3.241 с максимальным числом прыжков 30
    1 2 ms 11 ms 12 ms 172.16.1.254
    2 2 ms 2 ms 2 ms 10.20.3.2
    3 * * * Превышен интервал ожидания для запроса.
    4 * * * Превышен интервал ожидания для запроса.
    5 * * * Превышен интервал ожидания для запроса.

    Это до сервера, где firewall разрешает ping из других сетей
    C:\Users\Admin>tracert 172.16.3.240
    Трассировка маршрута к 172.16.3.240 с максимальным числом прыжков 30
    1 1 ms 1 ms 1 ms 172.16.1.254
    2 2 ms 2 ms 2 ms 10.20.3.2
    3 4 ms 7 ms 9 ms 172.16.3.240

    То же самое с маршрутизаторов в других филиалах
    А с маршрутизатора этого филиала работает
     
  10. Для этого используйте GRE + IP SEC.
     
  11. Посмотрите с какого адреса у вас пинг прилетает, когда пингуете 172.16.3.240 на этой машине.
     
  12. Max

    Max Участник

    upload_2017-11-16_13-3-35.png

    172.16.3.240 -> 172.16.1.98 ping с сервера на сервер
    172.16.0.250 -> 172.16.1.98 ping с виртуалки (win 7) на сервер
     
  13. chain=srcnat action=accept src-address=172.16.0.0/24 dst-address=172.16.100.0/24
    ошибка в NAT действие accept просто пропускает пакет, причем стоящие за ним правила NAT уже не исполняются. Используйте masquerade
     
  14. Max

    Max Участник

    Заменил accept на masquerade между ЦО и филиалом - ничего не поменялось
    Пингую из ЦО ПК в филиале
    Счётчик пакетов на правиле masquerade в ЦО увеличивается, в филиале нет - ноль
     
  15. wireshark что показывает ?
     
  16. Max

    Max Участник

    upload_2017-11-16_15-4-10.png
     

    Вложения:

  17. wireshark вы где запускаете ? Нужно снифить на той машине которую пытаемя пропинговать. Что бы понять NAT заработал или нет.
     
  18. Max

    Max Участник

    upload_2017-11-16_15-19-31.png

    это ping с 172.16.0.250 на 172.16.1.1
     
  19. а если отключаете правило NAT то source address меняется на 172.16.0.250. Так ?
     
  20. Max

    Max Участник

    Да
    отключил nat с обеих сторон, удалил все коннекты и source address стал 172.16.0.250