Проброс прямого ip адреса за NAT

[tierpunk]

Всем привет, по поиску ничего не нашёл или то что было в поиске не совсем то что мне нужно.

У меня есть подсеть из 16 прямых/внешних/белых ip адрес 89.0.0.1 - 89.0.0.16

Мне нужно дать внешний ip адрес клиентской машине находящейся за шлюзом на linux (iptables + nat)

Если я укажи любой из ip адресов на шлюзе то он будет отвечать на этот ip, но я хочу его пробросить на клиентскую машину таким образом, что бы клиент указывал внешний ip у себя на компе. или получал его по dhcp с привязкой по маку.

Может быть кто-то уже настраивал подобное или может сказать где что почитать умного.

ps Вариант с привязкой внешнего к внутренему ip не подходит т.к. некоторые программы будут работать некорректно. И выглядит это немножко не красиво.
pss Вариант с покупкой cisco или dlink тоже не то, потому что нет возможности тянуть провод от порта к абоненту.

[sash-kan]

я так понимаю, алгоритм примерно таков:

исходные данные шлюза:
внешний интерфейс — eth0
внутренний интерфейс — eth1. адрес, за ним закреплённый — 192.168.0.1
пробрасываемый адрес — 89.0.0.1

1. на клиентской машине (той, что должна откликаться на адрес 89.0.0.1) добавляем этот адрес к интерфейсу, смотрящему в локальную сеть:
$ sudo ip a a 89.0.0.1/32 dev <имя интерфейса. скорее всего eth0>
2. на клиентской машине дефолтным шлюзом должен быть указан 192.168.0.1
3. на шлюзе включаем ip_forward (если до сих пор не включен, что вряд ли):
$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
4. на шлюзе для интерфейса eth0 включаем proxy arp:
$ echo 1 | sudo tee /proc/sys/net/ipv4/conf/eth0/proxy_arp
5. на шлюзе добавляем маршрут к 89.0.0.1 через интерфейс eth1:
$ sudo ip r a 89.0.0.1/32 dev eth1
6. на шлюзе убираем (если вдруг был закрплён за интерфейсом eth0) ip-адрес 89.0.0.1.
7. всё.
осталось только лоск на iptables навести: нужный форвардинг пакетов разрешить, ненужный запретить и т.п.

p.s. если не работает, контролируем хождение пакетов tshark-ом/tcpdump-ом.

[tierpunk]

осталось только лоск на iptables навести: нужный форвардинг пакетов разрешить, ненужный запретить и т.п.

p.s. если не работает, контролируем хождение пакетов tshark-ом/tcpdump-ом.

Огромное спасибо. Обязательно напишу сюда о результате, правда попробовать получится не скоро.
А что за "лоск на iptables навести" ?

[patrius]

tierpunk

А что за "лоск на iptables навести" ?

это значит навести порядок )))
Например, почитать Руководство по iptables (Iptables Tutorial 1.1.19) и привести набор правил в соответствии с нуждами.

P.S.: Отдельно замечу, что клиенты с белыми адресами не должны натиться )). Соответственно после исполнения рекомендаций sash-kan 'a необходимо "сохранить" все в статику.

Удачь.

[Spider]

1. на клиентской машине (той, что должна откликаться на адрес 89.0.0.1) добавляем этот адрес к интерфейсу, смотрящему в локальную сеть:
$ sudo ip a a 89.0.0.1/32 dev <имя интерфейса. скорее всего eth0>

Этот адрес должен стать основным адресом интерфейса? У клиента не должно быть адреса внутри сети 192.168.0.0/24 ?

осталось только лоск на iptables навести: нужный форвардинг пакетов разрешить, ненужный запретить и т.п.

чтобы заработала поставленная задача нужно что-то обязательное добавлять? Или под ЛОСКом понималась только безопасность и прочая мура?

[sash-kan]

Этот адрес должен стать основным адресом интерфейса? У клиента не должно быть адреса внутри сети 192.168.0.0/24 ?

для gnu/linux ответ на оба вопроса: «без разницы». для других ядер/осей — не знаю.

чтобы заработала поставленная задача нужно что-то обязательное добавлять?

для того, чтобы задача заработала, нужные пакеты, как минимум, должны пропускаться через все необходимые таблицы.
а не нужные должны отбрасываться. если «всё разрешить», то, в принципе, из провайдерской сети _могут_ быть доступны машины вашей локальной сети. не только «подопытная», но и те, что имеют сугубо внутренние ip-адреса.

[Spider]

Понятно. С ходу пока не получилось, но пошёл колупать.
Заранее спасибо.

[sash-kan]

на всякий случай добавил пункт:

6. на шлюзе убираем (если вдруг был закрплён за интерфейсом eth0) ip-адрес 89.0.0.1.

а то человеку несведущему это не очень очевидно.

С ходу пока не получилось

«обложите» все участвующие в деле интерфейсы tshark-ами и смотрите, как проходят пакеты. обращайте внимание на адреса источника/получателя.

[Spider]

так. на машинке во "вне" пытаюсь пинговать "пробрасываемого" (в моём случае это 10.1.41.48) получаю такой ответ в tcpdump:

00:53:37.143918 IP 10.1.44.20 > 10.1.41.48: ICMP echo request, id 46425, seq 14, length 64
00:53:38.143805 IP 10.1.44.20 > 10.1.41.48: ICMP echo request, id 46425, seq 15, length 64
00:53:39.143678 IP 10.1.44.20 > 10.1.41.48: ICMP echo request, id 46425, seq 16, length 64
00:53:39.155906 IP 192.168.0.1 > 10.1.44.20: ICMP host 10.1.41.48 unreachable, length 92
00:53:39.155956 IP 192.168.0.1 > 10.1.44.20: ICMP host 10.1.41.48 unreachable, length 92
00:53:39.157508 IP 192.168.0.1 > 10.1.44.20: ICMP host 10.1.41.48 unreachable, length 92

Чудесным образом отправитель почему-то 192.168.0.1
В это время на "пробрасываемом":

01:19:31.692269 ARP, Request who-has 10.1.41.48 tell 192.168.0.1, length 28
01:19:31.692280 ARP, Reply 10.1.41.48 is-at 00:25:86:e9:cc:82, length 28

Вот. Что пока делать не пойму...

у пробрасываемого такие интерфейсы:

wlan0 Link encap:Ethernet HWaddr 00:25:86:e9:cc:82
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::225:86ff:fee9:cc82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50677 errors:0 dropped:0 overruns:0 frame:0
TX packets:61447 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:29338992 (29.3 MB) TX bytes:11556179 (11.5 MB)

wlan0:0 Link encap:Ethernet HWaddr 00:25:86:e9:cc:82
inet addr:10.1.41.48 Bcast:255.255.255.255 Mask:0.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Ну как видно у меня WiFi, но не думаю что это имеет значение.
В итоге получается, что сервер не перекидывает IP пакеты, затыкась на моменте построения ARP таблицы до "пробрасываемого".

сервер вообще не получает ARP либо игнорит его. С самого сервера уже не пингуется "пробрасываемый". Увы на севрере нет ни tcpdump ничего подобного. Со стороны "пробрасываемого" видно как сервер спрашивает АРП, и ему отвечают, но толку...

[sash-kan]

Вот. Что пока делать не пойму...

iptables.

[sash-kan]

в частности, проверьте цепочку forward на шлюзе — либо policy должна быть accept, либо должны явно присутствовать правила, пропускающие пакеты между 10.1.44.20 и 10.1.41.48

[Spider]

на шлюзе всё чисто. Политика ACCEPT на всё. Все цепочки пустые во всех таблицах.
Почему шлюз постоянно спрашивает MAC адрес клиента и игнорирует ответы?

Вроде получилось, но пришлось сделать так:
arp -H ether -i wlan0 -s 10.1.41.48 XX:XX:XX:XX:XX:XX

Теперь вроде как работает. Одно но. Почему-то на 22ой порт клиента из сети я не могу приконнектится, а на 22ой порт сервера могу. Но если сменить порт клиента на какой-нить 422, то уже могу.. Что за парадокс?

[sash-kan]

а нормальный gnu/linux на шлюз поставить нельзя?
тогда попытаюсь ткнуть пальцем в небо.
проверьте на шлюзе состояние этих переменных ядра:
$ cat /proc/sys/net/ipv4/conf/{default,eth1}/{arp_accept,arp_announce,arp_filter,arp_ignore,rp_filter}
0
0
0
0
0
0
0
0
0
0
если внутренний интерфейс у вас не eth1, исправьте команду.

Вроде получилось, но пришлось сделать так:
arp -H ether -i wlan0 -s 10.1.41.48 XX:XX:XX:XX:XX:XX

жестоко.
как я понимаю, по-человечески это звучит так (если я правильно понял, что команда, которую вы привели, выполнялась на шлюзе):
$ sudo ip n ch 10.1.41.48 lladr 00:25:86:e9:cc:82
кстати, после её выполнения эта запись, насколько вижу, по умолчанию будет иметь nud permanent (т.е., не устареет по таймауту). если нет, то просто добавьте эти слова в конце команды.

Почему-то на 22ой порт клиента из сети я не могу приконнектится, а на 22ой порт сервера могу.

см. iptables. на шлюзе и на клиенте.

[guglez]

Почему бы за место арп прокси не использовать DNAT? В простейшем варианте выглядит так:

iptables -t nat -I PREROUTING -d xx.xx.xx.xx -j DNAT --to-destination 192.168.yy.zz

iptables -t nat -I POSTROUTING -s 192.168.yy.zz -j SNAT --to-source xx.xx.xx.xx

Работает не на всех провайдерах. У тех, которые не предоставляют вам услугу "маршрутизируемая подсеть" придется поднимать алиас с белым айпишником на интерфейсе шлюза торчащем в инет.

PS а "парадоксы" у вас корее всего от того, что хотите изнутри попасть на свежеприсвоенный белый адрес. В простом варианте не будет работать.

[sash-kan]

Почему бы за место арп прокси не использовать DNAT?

Мне нужно дать внешний ip адрес клиентской машине

[guglez]

Раздал днат-ом 24ю подсеть белых адресов. В чем проблема-то? Из плюсов имеем возможность легко назначать адреса на шлюзе без перенастройки клиентов.

[sash-kan]

Раздал днат-ом 24ю подсеть белых адресов.

не понял вашей мысли. если клиентские машины будут иметь внешние ip-адреса, что должно фигурировать в вашем «днате»? пример приведите, если вас не затруднит.

[guglez]

Клиентские машины имеют серые адреса, а белый получают со шлюза DNAT-ом.
Простейший вариант выглядит так:

iptables -t nat -I PREROUTING -d xx.xx.xx.xx -j DNAT --to-destination 192.168.yy.zz
iptables -t nat -I POSTROUTING -s 192.168.yy.zz -j SNAT --to-source xx.xx.xx.xx

В этом случае из нутри сети (с серых адресов) нельзя будет попасть на белые адреса. С наружи все будет работать. Чтобы работало изнутри нужно приделыывать еще несколько правил, либо в DNS настроить вьюхи.

[Alex2ndr]

Раздал днат-ом 24ю подсеть белых адресов. В чем проблема-то? Из плюсов имеем возможность легко назначать адреса на шлюзе без перенастройки клиентов.

Оригинальное условие было таково -

Мне нужно дать внешний ip адрес клиентской машине находящейся за шлюзом на linux (iptables + nat)

Если я укажи любой из ip адресов на шлюзе то он будет отвечать на этот ip, но я хочу его пробросить на клиентскую машину таким образом, что бы клиент указывал внешний ip у себя на компе. или получал его по dhcp с привязкой по маку.

смотрите первый пост.

Таким образом DNAT исключается. Он подразумевает серые адреса во внутренней сети, а ТС нужны белые.

UPD:
Не успел...

[guglez]

Похоже, что меня переклинило на слове "пробросить"

[Spider]

Можно реанимировать тему? Когда-то тогда всё получилось, а сейчас не могу повторить фокус.
Сейчас у меня такая ситуация:
Сервер имеет 2 интерфейса:
eth0 - реальный IP
eth1 - 10.10.0.1
Клиент:
eth0 - реальный IP

если клиенту назначить на eth0 внутренний адрес и указать шлюзом сервер, а на сервере включить MASQUERADE то всё работает.
Но нужно пробросить реальный IP.
Вроде делаю всё как и в прошлый раз (по инструкции выше) но пакеты дальше eth1 на сервере не проходят. Если смотреть tcpdump -i eth1 -n, то видно как пакеты посланные с MAC адреса клиента с РЕАЛЬНЫМ адресам отправления и неким адресом назначения там есть, но вот из eth0 они уже не выходят. Что я забыл? ip_forward есть, proxy_arp есть. iptables правила все в ACCEPT и пустые.

Хелп

[sash-kan]

но вот из eth0 они уже не выходят

если я вас правильно понял, то потому, что забыли

указать шлюзом сервер

[Spider]

дык указал.
Пакеты до сервера доходят. МАК назначения серверный.
А вот в rp_filter и прочее может что забыл? там есть ещё all default lo в них надо ставить? Какая логика если не секрет?

[sash-kan]

значит, следующий этап — цепочки input, forward, output, через которые должны беспрепятственно пройти нужные вам пакеты·

[Spider]

вроде заработало, но ничего кроме ребута не сделал. Что-то куда-то поставил видать пока настраивал.
А iptables я прошерстил вдоль и поперёк все таблицы.

[Skyb]

я чегота не догоняю?
на сетевку/интерфейс назначить второй ip и закинуть за нат...?