LINUX.ORG.RU
ФорумAdmin

Fedora 25 - iptables SNAT пакеты исчезают

 ,


0

1

Столкнулся с очередным глюком, причём я почти уверен, что это именно глюк, т.к. работало раньше в этой же самой конфигурации. Суть: хочу с роутера пробросить на внутренний VPN-сервер входящие PPTP-соединения с использованием DNAT и SNAT. SNAT обязателен, т.к. для VPN-сервера этот роутер не всегда является шлюзом (он резервный), поэтому соединения на VPN должны приходить как-бы от внутреннего адреса роутера. Правила просты как по учебнику (GRE я опускаю, т.к. до него дело не доходит вообще):

iptables -t nat -A PREROUTING -i enp3s0 -p tcp --dport 1723 -j DNAT --to 192.168.1.1
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.1 --dport 1723 -j SNAT --to-source 192.168.1.52
192.168.1.1 - это VPN, а 192.168.1.52 - это роутер, что несколько необычно. enp3s0 - это, разумеется, внешний интерфейс роутера.

Так вот, пакеты благополучно приходят на внешний enp3s0, и пропадают в никуда, ни на одном интерфейсе больше не ловятся. Трассировка iptables -j TRACE показывает, что последним для пакетов выполняется этот SNAT, после этого глухо. Если убрать SNAT, то пакеты благополучно доходят до VPN, но, естественно, не «возвращаются», т.к. у него шлюз другой.

Вопрос: чо делать?

PS: «Обернул» правило SNAT в два правила -j LOG, одно перед SNAT, другое после. То, что перед SNAT, пишет в лог, то, что после него - не пишет. Т.е. на правиле SNAT пакет тупо пропадает.



Последнее исправление: shamus24 (всего исправлений: 1)

Ответ на: комментарий от vel

Там «2», но замена на «0» везде, где можно, ничего не изменила. Вероятно, какой-то всё-таки локальный глюк. Не исключено, что починится сбросом iptables или перезагрузкой, но пока этого нельзя сделать. Или очередной update что-то изменит, не исключено, что оно именно так и сломалось.

shamus24
() автор топика
Последнее исправление: shamus24 (всего исправлений: 1)
Ответ на: комментарий от shamus24

а какая версия ядра?

PS: «Обернул» правило SNAT в два правила -j LOG, одно перед SNAT, другое после. То, что перед SNAT, пишет в лог, то, что после него - не пишет. Т.е. на правиле SNAT пакет тупо пропадает.

дык ясен пень - SNAT/DNAT/MASQUERADE/REDIRECT - это ACCEPT для данной цепочки.

на счет TRACE - nat/POSTROUTING - это последняя цепочка которая трассируется. Дальше только tcpdump-ом на внутреннем интерфейсе.

vel ★★★★★
()
Ответ на: комментарий от vel

а какая версия ядра?

4.8.13-300.fc25.x86_64

SNAT/DNAT/MASQUERADE/REDIRECT - это ACCEPT для данной цепочки.

Угу. не учёл. Но то я уже от безысходности. «А что делать, что делать», как в анекдоте.

shamus24
() автор топика
Ответ на: комментарий от shamus24

в логах/dmesg нет какой-нибудь ругани на сеть ?

«conntrack -L -p tcp --dport 1723» что при этом показывает ?

tcpdump тоже не видит пакета ?

vel ★★★★★
()
Ответ на: комментарий от vel

в логах/dmesg нет какой-нибудь ругани на сеть ?

Нет ничего. Да и работает всё остальное-то. Роутер роутит-маскарадит без проблем. На всякий случай: правило маскарадинга такое:

-t nat -A POSTROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j MASQUERADE
Пакет, который теряется, до этого правила не добирается (по трейсу, да и по логике)

«conntrack -L -p tcp --dport 1723» что при этом показывает ?

Ноль

tcpdump тоже не видит пакета ?

Ну так им изначально и смотрел, а чем же ещё? Входящий виден, исходящего нет ни на одном интерфейсе, включая lo, специально проверил все.

shamus24
() автор топика
Ответ на: комментарий от shamus24

«conntrack -L -p tcp --dport 1723» что при этом показывает ?

Ноль

Это нужно посмотреть когда первый syn пришел. фильтр можно вообще убрать, если коннектов не много через эту машину. Если там пусто, значит что-то в системе криво одновилось или недообновилось.

vel ★★★★★
()

Глупость но, попробовать с 192.168.1.52 телнетом или nc ? Цепочку-то SNAT они также должны пройти и в conntrack -L -p tcp --dport 1723 отобразиться должны так же.

anc ★★★★★
()
Ответ на: комментарий от anc

Всё работает, кроме нужного варианта. И в SNAT проходит, и в conntrack появляется. Даже интересно стало. Надо, наверное, покопаться детальнее, снимая постепенно всю шелуху вокруг. Вдруг что-то таки мешает. Но для этого надо за консолью там сидеть, а то можно и доступ потерять.

Попробовал, кстати, убрать SNAT, установив этот роутер шлюзом на целевом сервере (соединение на VPN-сервер приходит от оригинального внешнего IP). Работает всё замечательно, VPN-соединение устанавливается.

shamus24
() автор топика
Ответ на: комментарий от shamus24

Еще один глупый вариант вместо SNAT

iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.1 --dport 1723 -j MASQUERADE 
А то вдруг вы где-то ошиблись мы же всего не знаем.

anc ★★★★★
()

Ёшкин же кот. Это conntrack helper! Вот эта строчка там есть в конфиге:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

В общем, порт 1723 начинает замечательно форвардиться, если её убрать. Только соединение, естественно, не устанавливается, т.к. роутер тогда не считает пакеты GRE как related, и они дропаются.

Но даже явно прописать разрешающее правило не достаточно, соединение GRE устанавливается в обратном направлении, от сервера к клиенту, и роутер без хелпера просто не знает куда этот пакет «отмаскарадить».

Сейчас проверю на ещё одном роутере в другом месте. Там конфигурация аналогичная, но ему не надо SNAT-ить VPN, там достаточно DNAT, и пока всё работает.

shamus24
() автор топика
Ответ на: комментарий от vel

Двойной NAT, в моём представлении, это цепочка из двух NAT друг за другом. К этой конфигурации отношения не имеет, он тут один. А грабли - с conntrack-ом. Обновление до «наисвежайшей» версии не помогло. Видимо, пока не заметили, редко используется такая комбинация.

shamus24
() автор топика
Ответ на: комментарий от shamus24

ну как хочешь называй. SNAT & DNAT для одного пакета - это источник граблей...

vel ★★★★★
()
Ответ на: комментарий от shamus24

Пальцем в небо. А точно modprobe ip_nat_pptp без это строки не помогает? Или может еще какой модуль есть?
А вообще pptp зло. Но интересно чем у вас закончиться :)

anc ★★★★★
()
Ответ на: комментарий от anc

А точно modprobe ip_nat_pptp без это строки не помогает?

К сожалению, нет. Мне не удалось до конца изучить взаимосвязь и разницу между nf_nat_pptp и nf_conntrack_pptp, но очень кажется, что nf_nat_pptp - это для исходящих из внутренней сети PPTP-соединений, а не наоборот. В любом случае - не работает.

А вообще pptp зло

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

shamus24
() автор топика
Последнее исправление: shamus24 (всего исправлений: 1)
Ответ на: комментарий от shamus24

Сейчас проверю на ещё одном роутере в другом месте.

Проверил. Всё так же, так что не случайный глюк.

Заодно нашёл более древнюю древность, и проверил как там. Там - нормально.

3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

Написать в «федору» багрепорт что-ли?

shamus24
() автор топика
Ответ на: комментарий от shamus24

А что ешё можно использовать для беспроблемного подключения к внутренней сети клиентов под оффтопиком?

Ну говорят l2tp вроде работает.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.