IPsec маршрутизация между 3 сетей
-
@operator2024
Не вижу никаких проблем в использовании дополнительных фаз 2 при таком виде подключения. Такой фокус ,который Вы описали, боюсь , не пройдёт с pf -
@konstanti спустя 4 дня проб и разных комбинаций я это понял, что либо что-то с фазами 2 нужно делать, либо юзать мой рабочий вариант.
К сожалению, я не нашел packet flow для pfSense. Вот для Mikrotik она есть и там понятно как цепочки работают и, где можно трафик перехватить и заюзать NAT, а тут я просто наугад это определяю по состояниям во вкладке Diagnostic - States.
Единственное что удалось найти это openbsd pf packet flow diagram, но там не все подробно и я не уверен, что она точная. -
@konstanti буду пробовать сделать этот вариант
Вариант NAT
шлюз А - 2 фазы 2
A-B
A-C
шлюз B - 4 фазы 2
B-A
C-A (1)
B-C
A-C (NAT используем 192.168.99.0/24 ) (2)
шлюз C - 1 фаза 2
C-BНужно уточнение, пометил цифрами 1 и 2.
Там где 1, нужно добавлять вторую фазу к С с удаленной сетью А, верно?
Там где 2, нужно добавлять вторую фазу к А с удаленной сетью, С через NAT/BINAT? -
@operator2024
Попробуйте , для начала, настроить по-правильному .
Без Nat. Nat нужен в этой схеме , когда нет доступа к настройкам удаленного шлюза . У Вас этот доступ есть . Смысла использования Nat я не вижу .На ваши вопросы отвечу - да .
-
@konstanti сделал без NAT, фазы поднялись (established), но трафик не идет
-
@konstanti на шлюзах А и С получается нужно добавить доп. интерфейс, чтобы трафик увидел маршрут через что ходить или всё должно заработать без дополнительного интерфейса.
Я под интерфейсом имею ввиду на А нужно добавить ip из сети 111, а на С из сети 88 -
Я Вам чуть выше показал средство для проверки трафика из консоли
Tcpdump и enc0 интерфейс
Начните со шлюза А - уходит ли трафик в направлении С
Далее смотрите то же самое на шлюзе B
Потом на шлюзе С
и будет понятно , где проблемакстати , мб проще сразу сделать туннель между А и С напрямую ?
-
@konstanti спасибо, проблема оказалась в правилах блокировки на А и С.
Сейчас всё подцепилось как нужно.@konstanti я тоже об этом подумал. Так будет проще.
Просто изначально я думал можно через NAT (как я описывал выше) сделать и поэтому не рассматривал прямой туннель между А и С -
This post is deleted! -
@operator2024
ICMP и TCP - разные протоколы
Возможно , что Вы разрешили только прохождение tcp трафика на нужном порту , а остальное блокируете -
@konstanti понимаю это, так и было. За 4 дня уже голова слабо соображает. Правило было только для ТСP трафика, сейчас исправил и заработало.
Напрямую кстати туннель можно сделать, но управлять не очень удобно будет.
Если нужно что-то разрешить или запретить. Особенно когда на всех подобных устройствах конфиг одинаковый. Устройства А и С это конечные устройства, а B что-то вроде шлюза в офисе, куда весь трафик идет. -
@operator2024
Да , решение в виде "топология звезда" - более правильное в плане администрирования всей системы в целом . НО !!!Если упадет любой из туннелей
A-B
или
B-C - то связи A-C не будет -
@konstanti да, но в данном случае это неважно.
Почему я изначально не хотел делать доп.фазы для такой задачи. Сама задача одному юзеру нужен доступ в удаленную сетку, на определенный ip для получения одного файлика.
Он коннектится, забирает файл и всё.
Файл мелкий, если дропнится туннель, он через время подымится и юзер файл заберет заново. -
Сама задача одному юзеру нужен доступ в удаленную сетку, на определенный ip для получения одного файлика.
Простой портфорвардинг или впн на С решил бы это (при наличие белого ip).
Зы. Если захочется чего-то "особенного", то можно поднять ipsec + ospf - с А до С и с А до В (В и С и так связаны).
Тогда при падении одного из линков связь с А до С останется. -
@werter OSPF - это уже лишнее в данной ситуации. Вопрос этот я решил через дополнительную фазу 2
