Virtual IP, машрутизация, каскад роутеров.
-
А зачем вам Кинетик в цепочке? Чего он умеет , чего не умеет пф ? Он точно вам необходим? ИМХО, лишнее звено и проблемы.
Если вам нужен его ви-фи - переводите его в режим ТД и пусть пф всем заведует. -
Внутри сети много серверов, и на Кинетике настроено много портфорвардов, весьма проблематично разом все перенастроить на использование новой адресации. Поэтому нужен переходный вариант когда доступны обе сети. В общем-то я в первом сообщении написал зачем все это - для обеспечения плавного перехода, чтоб пользователи, по возможности, вообще не заметили что что-то изменилось.
-
Пардон за настойчивость, но я бы сделал все одним махом оставшись после работы или же потратив немного своего времени в выходные , если в раб. время это невозможно.
Я не думаю что у вас там 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. Вы в ней смотрели? Там очень наглядно видно что, как и почему блокируется.
