[Solved] GRE tunnel over NAT

[leveler]

Есть железка с OpenWRT. Есть клиент в двумя компьютерами (А1 и А2) за натом. Есть у клиента два компьютера (Б1, Б2) в глобале.

Если сделать туннели А1-Б1 и А2-Б2, то всё работает. Если при этой комбинации ещё попытаться сделать туннель А2-Б1, то он не получится. Если истекает таймер записи

root@OpenWrt:/# cat /proc/net/ip_conntrack
gre      47 176 timeout=30, stream_timeout=180 src=10.252.0.250 dst=10.253.0.250 srckey=0x0 dstkey=0x0 packets=38 bytes=4712 src=10.253.0.250 dst=10.253.0.1 srckey=0x0 dstkey=0x0 packets=14699 bytes=1822676 [ASSURED] mark=0 use=3

, то можно сделать тунель А2-Б1, но тогда А1-Б1 не будет работать.

 

Как забороть это дело, если есть доступ к железке OpenWRT и возможность там чего-нибудь покрутить-поставить?

[Ivan_83]

- Использовать НАТ который умеет правильно натить gre.

- Не использовать gre.

[leveler]

По последнему пункту - не ко мне.

По первому - а какой умеет?

[Ivan_83]

в libalias есть плагин для gre, соответственно есть шансы заставить гре работать на natd, ipfw nat, ng_nat

[Abram]

Зачем всё так сложно-то? :)

Автору нужно просто поставить пакет с PPTP NAT helper. kmod-ipt-nat-pptp или что-то вроде этого.

[leveler]

Всем спасибо, победили проблему.

Понаставили модулей: nf_conntrack_proto_gre, nf_nat_proto_gre, nf_conntrack_pptp, nf_nat_pptp.

Два PPTP соединения установлены на один внешний сервер. Я так понимаю, различает железка их по Call ID - новому полю в подправленной версии GRE для PPTP.

[Abram]

Я так понимаю, различает железка их по Call ID - новому полю в подправленной версии GRE для PPTP.

Именно.