LINUX.ORG.RU
ФорумAdmin

Почему пакеты не попадают в nat PREROUTING?

 , больная фантазия


0

2

Имеем:

                   интернет
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ||                                 ||
 _____||______                        ___||___
(   1.2.3.4   )                      (        )
(             )                      (   ws1  )
(   router    )                      (________)
(             )
(_10.0.0.1/24_)
      ||
      ||
   ___||___
  (        )
  ( switch )========================================
  (________)          ||                           ||
                 _____||____                  _____||____
                (10.0.0.2/24)                (10.0.0.5/24)
                (           )                (           )
                (___server__)                (____ws2____)

На роутере порт 22 проброшен на порт 22 машины server.

Делаем:

server# iptables -t raw -A PREROUTING -j LOG --log-prefix "raw PREROUTING "
server# iptables -t mangle -A PREROUTING -j LOG --log-prefix "mangle PREROUTING "
server# iptables -t nat -A PREROUTING -j LOG --log-prefix "nat PREROUTING "
server# iptables -t nat -A PREROUTING -p tcp --dport 4444 -j DNAT --to-destination 10.0.0.5:22
server# iptables -t nat -A POSTROUTING -j MASQUERADE
ws1# ssh -L 5555:10.0.0.2:4444 1.2.3.4 -fN
ws1# ssh localhost -p 5555

Смотрим логи на server - в raw PREROUTING пакеты идут, в mangle PREROUTING идут, а в nat PREROUTING - не идут, нету. Исходя из схемы, должны идти.

Что хотелось получить:

возможность вместо ssh обращаться на ws2 через DNAT, настроенный на server1, к сервису, шифрование у которого внушает доверия меньше, чем ssh, и иметь шифрованное соединение. Из-за того, что пакеты, выходящие из ssh-туннеля, не попадают в nat PREROUTING, не получается сделать DNAT, и мой план не работает.

Где в реализации плана я допустил ошибки?

Где в реализации плана я допустил ошибки?

не читал man iptables

Локально сгенерированные пакеты не попадают в PREROUTING
DNAT для них надо настраивать в OUTPUT

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

не попадают в PREROUTING

локально сгенерированные

man раз читал, и уже подумал о том, что эти пакеты могут считаться локально сгенерированными, но почему тогда они попадают в PREROUTING в другие таблицы?..

Может, я плохо себе представляю, как работает туннель. Так значит, вылезшие оттуда пакеты считаются исходящими?

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

Есть странная идея. Может iptables слишком умный и не делает маршрутизацию пакетов в той же подсети? У сервера 10.0.0.255 и у клиента 10.0.0.255.

delete83 ★★
()

Кстати, а обратный маршрут на клиенте ws2 как настроен? Он прямо через роутер будет стучаться на ws1?

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

Потому что пакеты от ws1 в любом случае обрабатываются всеми тремя таблицами. nat - первая таблица, которая пытается принимать решение, куда направить пакет. До нее пакет можно только дропнуть или модифицировать.

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

По сути, в вашей схеме server должен быть прозрачным для ws2 и ws1. Если не считать модификации исходящего порта для ws2 в входящих на него пакетах.

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

В моем описании айпишники и порты изменены для уменьшения путаницы.

Aug  9 14:00:30 everest kernel: [313614.525034] raw PREROUTING IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.8 DST=192.168.1.8 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2538 DF PROTO=TCP SPT=60386 DPT=1723 WINDOW=32792 RES=0x00 SYN URGP=0                       
      
Aug  9 14:00:30 everest kernel: [313614.525081] mangle PREROUTING IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.8 DST=192.168.1.8 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2538 DF PROTO=TCP SPT=60386 DPT=1723 WINDOW=32792 RES=0x00 SYN URGP=0              
            
Aug  9 14:00:30 everest kernel: [313614.525121] INPUT IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.8 DST=192.168.1.8 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2538 DF PROTO=TCP SPT=60386 DPT=1723 WINDOW=32792 RES=0x00 SYN URGP=0         
                             
Aug  9 14:00:30 everest kernel: [313614.525174] raw PREROUTING IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.8 DST=192.168.1.8 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1723 DPT=60386 WINDOW=0 RES=0x00 ACK RST URGP=0         
                       
Aug  9 14:00:30 everest kernel: [313614.525210] mangle PREROUTING IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.8 DST=192.168.1.8 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1723 DPT=60386 WINDOW=0 RES=0x00 ACK RST URGP=0           
                  
pianolender ★★★
() автор топика
Ответ на: комментарий от pianolender

Это все не то. Пакеты, шныряющие по локальному интерфейсу к делу отношения не имеют. Нужны те, которые идут по внешнему интерфейсу.

Советую поправить правила, чтобы в лог не сыпал мусор с локального интерфейса.

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

У этих пакетов «с локального интерфейса» src и dst вполне себе из сетки сервера. Это не мусор, это именно те пакеты, которые не туда попали.

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

Примерно так.

server# iptables -t raw -A PREROUTING -i ! lo -j LOG --log-prefix "raw PREROUTING "
server# iptables -t mangle -A PREROUTING -i ! lo -j LOG --log-prefix "mangle PREROUTING "
server# iptables -t nat -A PREROUTING -i ! lo -j LOG --log-prefix "nat PREROUTING "
server# iptables -t nat -A PREROUTING -p tcp --dport 4444 -j DNAT --to-destination 10.0.0.5:22
server# iptables -t nat -A POSTROUTING -j MASQUERADE

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

Единственное, что в логе лишнее - это одна запись про пакет в INPUT, но она тоже относится к тем пакетам, которые не туда попали.

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

Выдержка из Википедии:

Спецификация протокола была опубликована как «информационная» RFC 2637 в 1999 году. Она не была ратифицирована IETF. Протокол считается менее безопасным, чем IPSec. PPTP работает, устанавливая обычную PPP сессию с противоположной стороной с помощью протокола Generic Routing Encapsulation. Второе соединение на TCP-порте 1723 используется для инициации и управления GRE-соединением. PPTP сложно перенаправлять за сетевой экран, так как он требует одновременного установления двух сетевых сессий.

Это не те пакеты.

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

Это в случае, если та машина, к которой обратились, не пытается редиректить все входящие пакеты на левую машину. Вопрос только в том, на какой порт ws1 бросает запрос на поднятие туннеля. Если 4444, то server вообще не при делах. А если на другой, то тебе пакеты на локальном интерфейсе с портом 1723 тоже не нужны. Это служебные пакеты для обслуживания тоннеля.

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

Номер порта 1723 не имеет никакого отношения ни к ssh, ни к моему тоннелю. Это просто порт, на который я пробросил туннель и с которого лювлю пакеты для DNAT'а.

Так и знал, что от лога все только запутаются.

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

Сейчас они у меня там оба есть. На сервере на самом деле фигова каша, но на ясность того, что я изложил, это не повлияло.

А вот людей вводит в ступор.. Ладно, вкурю ман получше.

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

Как хотите, но я бы вам посоветовал все же посмотреть, какие пакеты ходят по внешнему интерфейсу, а потом заглянуть в логи tcpdump или wireshark. Там все будет понятнее.

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

Не, ничего лучше логов iptables в данном случае не придумаешь, а задачу я уже решил.

Всем спасибо, хоть всего я и не понял.

pianolender ★★★
() автор топика

Схема не совсем правильная, то, что идёт через lo идёт по другому:

[sending local process]
|
V
raw,mangle,nat(1),filter OUTPUT chains
|
V
mangle,nat(1) POSTROUTING chains
|
V
[loopback interface]
|
V
raw,mangle PREROUTING chain
|
V
mangle,filter INPUT chains
|
V
[receiving local process]
http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

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