Исходное сообщение
"GRE/IPSEC over NAT" Отправлено PavelR, 04-Июл-17 10:58
>[оверквотинг удален] >> NAT. >> iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT >> Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно. >>>[uzer@R1 ~]$ sudo iptables -nvL -t nat >>>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) >>> pkts bytes target     prot opt in     out     source               destination >>>   48  3512 MASQUERADE  all  --  *      ens3    0.0.0.0/0            0.0.0.0/0 > Нет, не то. > Во вторых R1 здесь ни при чём, через R1 должен ходить уже > зашифрованный трафик между H1 и R2. Ок, почти определились с концами туннеля. > Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC > между H1 и R2. Не понял, что за сопоставление имеется ввиду и зачем. > Проблема на R2 запихать GRE в IPSEC, и на R1 я должен > видеть только пакеты UDP на порт 4500 и ничего более. По > крайней мере в тунельном режиме IPSEC, как у меня. Но я > вижу GRE пакеты. SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым IPSEC. Не забудьте после отстройки туннеля закрыть файрволлом возможность отправки нешифрованного трафика, иначе этому шифрованию грош цена. Также рекомендую strongswan и его документацию, мне показалось удобным. При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло.

Ваше сообщение
Имя*:
EMail:	Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >>> NAT. >>> iptables -t nat -I POSTROUTING -d 192.168.2.202 -j ACCEPT >>> Тогда он попадет в шестеренки IPSEC-шифрования и уйдет тунеллированно-шифрованно. >>>>[uzer@R1 ~]$ sudo iptables -nvL -t nat >>>>Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) >>>> pkts bytes target prot opt in out source destination >>>> 48 3512 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0 >> Нет, не то. >> Во вторых R1 здесь ни при чём, через R1 должен ходить уже >> зашифрованный трафик между H1 и R2. > Ок, почти определились с концами туннеля. >> Во первых contrack не сможет сделать сопоставление пакетов при начальной инициации IPSEC >> между H1 и R2. > Не понял, что за сопоставление имеется ввиду и зачем. >> Проблема на R2 запихать GRE в IPSEC, и на R1 я должен >> видеть только пакеты UDP на порт 4500 и ничего более. По >> крайней мере в тунельном режиме IPSEC, как у меня. Но я >> вижу GRE пакеты. > SA создана для "192.168.2.202/32[gre/0] === 10.0.1.2/32[gre/0]", а туннель почему-то > между "SRC=192.168.2.202 DST=192.168.2.201", хотя должен быть также к DST 10.0.1.2. > В итоге у GRE-пакетов "не те" адреса, поэтому они не перехватываются поднятым > IPSEC. > Не забудьте после отстройки туннеля закрыть файрволлом возможность отправки нешифрованного > трафика, иначе этому шифрованию грош цена. > Также рекомендую strongswan и его документацию, мне показалось удобным. > При подключении с windows/android из-за кучки NAT-ов проблем вообще не возникло.
	Введите код, изображенный на картинке: