Многим известна схема проброса портов с роутера на сервер, находящийся в локальной сети DNAT+SNAT. В таком случае IP входящих соединений будут принадлежать внутреннему адресу роутера.
Возможно ли сделать так, чтобы на сервер транслировались пакеты с их реальными IP, без SNAT, и сервер бы смог на них беспрепятственно отвечать при условии, что сервер не должен иметь выход в интернет. Ответы на пакеты должны перенаправляться роутеру, а тот их уже отправит туда, откуда пришел запрос. Т.е. функционал DNAT+SNAT, но без SNAT, т.к. маршрут выхода в интернет отсутствует.
В таком случае IP входящих соединений будут принадлежать внутреннему адресу роутера
Это не так. При DNAT подменяется адрес назначения, а не источника. На роутер приход пакет с адресом назначения равным внешнему адресу роутера и он этот адрес заменяет на внутренний адрес хоста, на который делается проброс, и отправляет пакет дальше
Тут смысл в том, что DNAT работает, а ответ от внутреннего сервера идёт на внешний IP, к которому у внутреннего сервера нет доступа. Т.е. как-то надо ответ обработать на самом сервере, отправить его на роутер, и там уже послать адресату.
Всё это сделать нужно без всяких маршрутов в локальной сети, при условии что роутер и внутренний сервер работают в одной подсети.
Не очень уверен, сработает ли, но можно попробовать сделать SNAT на внутренний адрес роутера, когда пакет будет уходить с роутера через интерфейс локальной сети
Допустим у какого-то хоста в инете адрес 1.1.1.1, у вашего роутера внешний адрес 2.2.2.2
Хост 1.1.1.1 шлет пакет src 1.1.1.1 sport 1111 dst 2.2.2.2 dport 80
Первое правило транслирует пакет в src 1.1.1.1 sport 1111 dst 192.168.0.2 dport 80
Второе правило транслирует пакет в src 192.168.0.1 sport 4242 dst 192.168.0.2 dport 80
Т.е. внутренний сервер будет считать, что пакет пришел от роутера и отправит ответный пакет:
src 192.168.0.2 sport 80 dst 192.168.0.1 dport 4242
Этот пакет по таблице трансляции преобразуется в src 192.168.0.2 sport 80 dst 1.1.1.1 dport 1111
А потом второй раз в src 2.2.2.2 sport 80 dst 1.1.1.1 dport 1111
Хост 1.1.1.1 считает, что он обменивается пакетами с роутером, и внутренний сервер считает, что он обменивается пакетами с роутером. А на самом деле происходи вот такая петрушка
Я полагал на сервере создать правило postrouting --sport 80, чтобы пакет попал на роутер. На роутере же этот пакет отправить в сеть. но не получается. поэтому задался вопросом, а возможно ли так?
кстати, как заставить tcpdump дампить postrouting пакеты? или мне придется использовать хаб и на хабе сниффить пакеты?
Как вариант, можно создать таблицу маршрутизации в rt_tables, в которую добавить маршрут по умолчанию, на входящие соединения на внутреннем сервере ставить connmark, а в ответных пакетах connmark восстанавливать в nfmark и по ip rule заворачивать на таблицу с маршрутом по умолчанию
Могу примерно накидать здесь. На роутере должно быть правило для DNAT (первое из тех, что я приводил). Все остальное — на внутреннем сервере. В ядре на сервере должна быть поддержка всей этой кухни, и установлены iptables и iproute2.
В /etc/iproute2/rt_tables добавляете строку
1 dnat
Добавляете маршрут по умолчанию в таблицу dnat:
ip route add default via 192.168.0.1 table dnat
Пара правил в iptables:
iptables -t mangle -A PREROUTING -p TCP --dport 80 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1
iptables -t mangle -A OUTPUT -p TCP --sport 80 -j CONNMARK --restore-mark
Мде, с учётом прочтённого выше могу сказать, что много слишком вы хотите получить. Вас должно спасти проксирование, правда тут уже не только netfilter будет задействован.
Эм, а что мешает сделать обратный NAT, когда пакеты отправляясь на роутер, отправляются на внешний IP, доступа к которому у внутреннего сервера нет?
картина то одна и та же:
внешний клиент -> пакет -> преобразование IP
внутренний клиент -> пакет -> преобразование IP
