Virtual IP, машрутизация, каскад роутеров.



  • Для перехода на новую маршрутизацию в локальной сети пытаюсь настроить следующую схему.

    Router ────── pfSense ───── New LAN
      │
      └───────── Old LAN

    Router - Zyxeel Keenetic, IP 192.168.1.1
    pfSense -  pfSense 2.1-RELEASE-pfSense (amd64), IP на интерфейсе 172.16.20.1/22 + Virtual IP 192.168.1.250/24
    New LAN - 172.16.20.0/22
    Old LAN - 192.168.1.0/24
    На Кинетике настроен маршрут  172.16.20.1/22 –> 192.168.1.250

    Что необходимо:
    Чтоб машины из старой сети "видели" машины в новой сети и наоборот, сейчас это не работает. Когда все машины фактически будут работать в сети 172.16.20.0/22 интернет "шланг" будет подключен напрямую в pfSense, таким образом планируется достигнуть плавной и безболезненной миграции в новое адресное пространство.

    Таблица маршрутов такая:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            192.168.1.1        UGS        0      796    em0
    127.0.0.1          link#6            UH          0      759    lo0
    172.16.20.0/22    link#1            U          0      734    em0
    172.16.20.1        link#1            UHS        0        0    lo0
    192.168.1.0/24    link#1            U          0      706    em0
    192.168.1.250      link#1            UHS        0        0    lo0

    C Кинетика идет пинг на 192.168.1.250  и на 172.16.20.1, но не идет на машину в New LAN 172.16.22.1
    С pfSense идут пинги везде, на 192.168.1.1 (Router), 192.168.1.175 (машина в Old LAN), 172.16.22.1 (машина в New LAN)
    С машины в New LAN пинги идут на pfSense, на Кинетик и в интернет, но не идут в Old LAN
    C машины в Old LAN пинги идут на pfSense, на Кинетик и в интернет, но не идут в New LAN соответственно
    Таким образом обе сети имеют доступ в интернет, но не имеют связи между собой.

    NAT-а нет.

    Файрвол открыт полностью

    Что я упускаю? Если нужна какая-то еще информация о настройках pfSense - пишите какая.



  • А зачем вам Кинетик в цепочке? Чего он умеет , чего не умеет пф ? Он точно вам необходим? ИМХО, лишнее звено и проблемы.
    Если вам нужен его ви-фи - переводите его в режим ТД и пусть пф всем заведует.



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



  • Пардон за настойчивость, но я бы сделал все одним махом оставшись после работы или же потратив немного своего времени в выходные , если в раб. время это невозможно.
    Я не думаю что у вас там 5 десятков пробросов портов, правда. Откройте интерфейс зюхеля , откройте настройки портфорвардинга в пф и внимательно перенесите.

    P.s. Честно, не заморачивайтесь. Захотите сделать в два этапа - просто намнооого больше время потратите да еще и ошибок наделаете. ИМХО, лучшее - враг хорошего.
    P.p.s. У вас уже NAT неверно настроен. Верните его в авторежим.



  • Одним махом - никак. За пробросами сервера, с которыми работают люди. Притом на данный момент, я даже не имею доступа к настройкам этих серверов. Хотя это конечно решаемый вопрос, просто до этого дело еще не дошло. Вы предлагаете сменить на всех серверах адресацию, перенастроить проброс портов на новом устройстве, и надеяться что все это взлетит сразу и без проблем? По моему опыту - это маловероятно. А следовательно, люди останутся без работы, короче ничего хорошего.
    Пробросов не 5 десятков, но десятка 3 есть, это исторические наслоения, которые были сделаны до меня, а я собираюсь от них избавиться.
    А кроме серверов есть люди, которые просто в офисе работают за компьютером, и у них настроен сетевой принтер, по IP естественно, DNS же кому надо было подымать… И вот, к перенастройке нескольких десятков пробросов, настройке сети примерно в 10-ке серверов, добавляется перенастройка принтера у дюжины с лишним людей.
    В общем объем работ не на вечер, и косяки будут еще потом вылазить наверняка.

    Это не первая сеть которую я настраиваю, и не первый FreeBSD маршрутизатор , думаю на чистой FreeBSD проблемы бы не возникло, но зато это первый раз, когда я решил что pfSense решит все необходимые задачи, притом с удобством большим чем ручная правка конфигов. Я не великий сетевой гуру определенно, но в целом достаточно опыта чтоб настроить маршрутизацию между двумя сетями.
    Почему я решил спросить на форуме - потому что pfSense все же отдельная система которая работает не так, как "голая" FreeBSD, имеет свои тонкости. Судя по таблице маршрутов - все должно работать, но не работает, из чего я сделал выводы, либо я чего-то очевидное упускаю из виду (туплю в общем), либо сказывается какая-то особенность pfSense о которой я понятия не имею.

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

    Что неверно с моим НАТом? Он отключен, он мне не нужен сейчас, к пф-у не подключен внешний канал с публичными адресами, зачем мне что-то НАТить? В интернет пакеты натятся на зухеле, а между двумя приватными сетями пакеты не надо натить, надо их маршрутизировать.



  • Ок. Вам виднее по-ситуации.
    Немного непонятна схема .

    Как сделал бы я:

    172.16.20.1/22 - на LAN pfsense
    192.168.1.250/24 - на WAN pfsense со шлюзом\DNS 192.168.1.1

    И зачем вам Virtual IP ?

    Далее :

    0. Выключаем на время все fw, антивирусы etc. (сторонние и нативные) на проверямых машинах в обеих сетях.
    1. Отключаем блокирование "серых" сетей на WAN pfsense.
    1.1. Включаем NAT в автомате на pfsense (на время!).
    2. Включаем логирование fw на pfsense
    3. Оставляем только одно правило на LAN и WAN pfsense - разрешено всё всем и по всем протоколам
    3. Запускаем tracert с машины в новой сети (за pfsense) до машины в старой. Смотрим на каком этапе затык.
    4. Если затык после WAN pfsense - переводим NAT в режим мануала и рисуем правило вручную с NO NAT на WAN pfsense для сети 172.16.20.0/22.
    5. Если и это не поможет - разбирайтесь c вашим Зюхелем.

    P.s. И да, я надеюсь у машин в новой сети шлюзом указан LAN пфсенса - 172.16.20.1/22 ?
    P.p.s.

    На Кинетике настроен маршрут  172.16.20.1/22 –> 192.168.1.250

    Правильнее :
    В сеть 172.16.20.0/22 "ходить" через 192.168.1.250.
    Если же все равно не получается - на время вместо Зюхеля поставить простой свитч и проверить.

    Можно еще попробовать объединить LAN и WAN pfsense в бридж.



  • На 1 интерфейсе все висит потому как в WAN будет включен внешний канал в конце концов, и если сейчас настраивать используя его - то потом, возможно, опять придется "все ломать" в пределах пф-а. Понятно что с 2-мя сетевухами все понятнее выглядит, я даже притащил из дома сетевушку 2-ю чтоб на них разные сети настроить, но она не завелась такое было уже у меня на 8-й ветке FreeBSD, просто и быстро починить не удалось, использовал другую сетевуху в итоге, а там и 9-ка подоспела.

    Попробую по предложенной вами схеме, на самом деле тоже есть сомнения в работе маршрутизации на зухеле, но в интернет он выпускает машину из 172 сети, значит как-то она работает.

    PS

    И да, я надеюсь у машин в новой сети шлюзом указан LAN пфсенса - 172.16.20.1/22 ?

    Само собой.

    PPS

    Правильнее :
    В сеть 172.16.20.0/22 "ходить" через 192.168.1.250.

    Сказать правильнее так, согласен, но смысл был донесен главное :)



  • В итоге проверив вариант:

    0. Выключаем на время все fw, антивирусы etc. (сторонние и нативные) на проверямых машинах в обеих сетях.
    1. Отключаем блокирование "серых" сетей на WAN pfsense.
    1.1. Включаем NAT в автомате на pfsense (на время!).
    2. Включаем логирование fw на pfsense
    3. Оставляем только одно правило на LAN и WAN pfsense - разрешено всё всем и по всем протоколам
    3. Запускаем tracert с машины в новой сети (за pfsense) до машины в старой. Смотрим на каком этапе затык.
    4. Если затык после WAN pfsense - переводим NAT в режим мануала и рисуем правило вручную с NO NAT на WAN pfsense для сети 172.16.20.0/22.
    5. Если и это не поможет - разбирайтесь c вашим Зюхелем.

    Вернулся обратно к своему варианту на 1-ом интерфейсе, потому как в таблице маршрутизации никакой разницы нет (кроме имен интерфейсов), да и в результате тоже, при использовании WAN порта, все проблемы сохраняются.

    Если же на машине в Old LAN (192.168.1.20) прописать шлюзом по умолчанию pfSense т.е 192.168.1.250, то есть связь между сетями и выход в интернет тоже.
    Но если включить в консоли "10) Filter Logs" то видим там, что странным образом влияет на работу интернета, он вроде как работает, но не совсем.

        192.168.1.20.61474 > 173.194.71.147.443: Flags [FP.], cksum 0xdb7b (correct), seq 3371874979:3371875084, ack 4219013402, win 258, length 105
    00:00:00.115961 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28695, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61482 > 54.229.20.0.80: Flags [.], cksum 0x5cee (correct), ack 313932758, win 259, length 0
    00:00:00.304373 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28696, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61482 > 54.229.20.0.80: Flags [F.], cksum 0x5cee (correct), seq 2809880254, ack 313932758, win 259, length 0
    00:00:00.134213 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 18941, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61421 > 74.125.143.100.443: Flags [R], cksum 0xb6e4 (correct), seq 3004498629, win 0, length 0
    00:00:00.052865 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 8182, offset 0, flags [DF], proto TCP (6), length 114)
        192.168.1.20.61293 > 195.19.71.17.143: Flags [P.], cksum 0x1bad (correct), ack 3707938538, win 256, length 74
    00:00:00.266186 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13812, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0xf242 (correct), ack 1744882530, win 256, length 0
    00:00:00.043149 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28697, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61482 > 54.229.20.0.80: Flags [.], cksum 0x5cee (correct), ack 313932758, win 259, length 0
    00:00:00.149918 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13813, offset 0, flags [DF], proto TCP (6), length 52)
        192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0x55b4 (correct), ack 1744882530, win 256, options [nop,nop,sack 1 {1744882451:1744882530}], length 0
    00:00:00.239989 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13820, offset 0, flags [DF], proto TCP (6), length 52)
        192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0x55b4 (correct), ack 1744882530, win 256, options [nop,nop,sack 1 {1744882451:1744882530}], length 0
    00:00:00.131035 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 308, offset 0, flags [DF], proto TCP (6), length 40)
        192.168.1.20.61483 > 65.55.223.38.40011: Flags [R], cksum 0x91cf (correct), seq 2785096126, win 0, length 0
    
    

    И честно говоря не понятно, каким правилом это все блочится, правила я не менял они такие как и на скриншоте выше. И вообще, я добавлял только разрешающие правила, так что это какое-то стандартное правило. Как-то можно это правило убрать?

    Вторая проблема с Кинетика не проходит пинг на машины в New NET на pfSense видим

    20:11:19.714612 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1024, length 1480
    20:11:19.714628 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1024, length 1480
    20:11:20.715674 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1280, length 1480
    20:11:20.715689 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1280, length 1480
    

    т.е. до pfSens-а пакеты доходят - а дальше нет - проверил даже вайршарком на машине 172.16.22.1 до нее пакеты не доходят.



  • Вернулся обратно к своему варианту на 1-ом интерфейсе

    Ок, попробуем след. :

    1. Оставляем WAN пфсенса без кабеля и переводим его на DHCP.
    2. Создаем Virtual IP на 192.168.1.250/24 типа IP Alias
    3. Заходим в Routing и добавляем шлюз - Interface: LAN , Name: любое , Gateway:192.168.1.1 . Галка Default Gateway - снята.
    4. Заходим в System: Static Routes . Задаем маршрут Destination network : 192.168.1.0/24, Gateway: выбираем созданный в предыдущем меню.
    5. Идем в Firewall: Rules:LAN и рисуем самым верхним правило - разрешено все всем и всюду , протокол - любой.

    NAT оставьте в автомате.



  • Снял галку Default Gateway, прописал статический маршрут - потерял доступ из 192 сети!
    При попытке пинга наблюдаю следующее, со стороны откуда выполняется пинг - вижу просто "Превышен интервал ожидания запроса", а вот на самом пф-е вижу и запросы и даже ответы

    13:17:54.870008 IP 192.168.1.20 > 192.168.1.250: ICMP echo request, id 1, seq 140, length 40
    13:17:54.870048 IP 192.168.1.250 > 192.168.1.20: ICMP echo reply, id 1, seq 140, length 40
    13:17:59.633828 IP 192.168.1.20 > 192.168.1.250: ICMP echo request, id 1, seq 141, length 40
    13:17:59.633844 IP 192.168.1.250 > 192.168.1.20: ICMP echo reply, id 1, seq 141, length 40
    
    ```только вот до клиента они не доходят.


  • Хм..А в логах fw что?

    P.s. И последнее - объединить в бридж LAN и WAN (подключив WAN и получив от момеда адрес\прописав вручную)



  • Как лучше логи посмотреть? Через консоль "10) Filter Logs" или есть лучше методы?
    Бридж попробую.



  • Т.е. во всех этих "плясках" вы до сих пор логи fw и не смотрели?! Жесть… :(



  • Кто сказал что я не смотрел? Я смотрел так как описал выше, через консоль.



  • О какой консоли речь?
    Я о вкладке Diagnostics:System logs:Firewall.  Вы в ней смотрели? Там очень наглядно видно что, как и почему блокируется.