Проблема: iptables forward public IP, no NAT/Masquerade

[Action]

Ситуация: Debian i386, две машины, обе в локалке, плюс одна в Инете. У обеих public IP адреса. Суть в том, чтобы первая машина, которая в Инете, пробрасывала (forward) вторую с public IP. NAT работает прекрасно, и пинг идёт, и всё супер, а вот без NAT, так, как, собственно, надо, не получается. Куда там что писать? "sudo iptables -A FORWARD -j ACCEPT" или то же самое с добавкой "-o ppp0" не помогает, Даже с policy ACCEPT везде.
Заранее спасибо.

[BIgAndy]

две машины, обе в локалке, плюс одна в Инете. У обеих public IP адреса.

O_o... Это как "Эй, вы, трое, оба сюда - бегОм"???

пробрасывала (forward) вторую с public IP

Как пробрасывала? Что пробрасывала? Куда пробрасывала?

ВЫ толком объясните или нарисуйте схему

Куда там что писать?

Ну, в СпортЛото можно для начала

В общем, нифига не понятно....

[Action]

...

Ваш стиль общения в некоторой степени напоминает то, что у современной неформальной молодёжи принято называть "трололо". С другой стороны, не понимаю такой вещи: ещё вчера я правил пост, добавлял детали, переформулировал так, чтобы было понятнее, так какого же * этой правки теперь здесь нет?
Короче, перефразирую. Две машины. Обе имеют подключение к локальной сети, и одна из них имеет ещё прямое подключение к Интернету. У обеих машин "белые адреса", или как это у вас называется, public IP address. Та, что имеет прямое подключение к Интернету, должна работать как роутер и маршрутизировать (forward) соединения другой машины так, чтобы был виден белый IP, без NAT.

[sash-kan]

интерфейс, через который машина подключена в глобальную сеть, это широковещетельное (ethernet) или туннелируемое (ppp) соединение?

[Action]

интерфейс, через который машина подключена в глобальную сеть, это широковещетельное (ethernet) или туннелируемое (ppp) соединение?

ppp, через ADSL. В файле /etc/ppp/peers/(name-of-isp) присутствует строка plugin rp-pppoe.so eth0. Короче, соединение ADSL/PPPoE устанавливается через eth0, потом возникает/поднимается ppp0 и дальше вся коммуникация с Инетом идёт через него.

[Action]

Создавая алиасы на картах роутера, вижу, что проблема не в нём, он проводит пинги на любые адреса. Интерфейс, через который идёт клиент, один, алиасы на другом. Похоже, что проблема реально на стороне провайдера. Пробовал arping, пока без видимых результатов.

[BIgAndy]

Ваш стиль общения в некоторой степени напоминает то, что у современной неформальной молодёжи принято называть "трололо".

Вот, знаете, таки да.. Вы, возможно, хорошо осведомлены о неформальных течениях. . ОДнако надо убедится, что вы либо понимаете саму абсурдность формулировок в ТС, либо таки это тоже стиль общения - камлание для вызова телепатов. Представляете, каково читать и расшифровывать подобное?

Короче, перефразирую. Две машины. Обе имеют подключение к локальной сети, и одна из них имеет ещё прямое подключение к Интернету. У обеих машин "белые адреса", или как это у вас называется, public IP address.
.....ppp, через ADSL

/me не понимает, почему бы не назначить real ip самому модему?
Не, ну, ладно.. Как говорится, Хозяин-барин!
Таки, по-русски: вам надо организовать DMZ или портфорвардинг на два интерфейса с real ip, нахдящимися за "серым" IP, назначаемым провайдером на "внешний" интерфейс роутера через adsl железку??
Уф!!!

Та, что имеет прямое подключение к Интернету, должна работать как роутер и маршрутизировать (forward) соединения другой машины так, чтобы был виден белый IP, без NAT.

Конечно, не моё дело, но таки объясните, а зачем так криво? Зачем тогда NAT? Не примите за назойливое поведение, от жтогозависят правиля и цепочки iptables

[sash-kan]

ppp

ага, раз это не ethernet, значит, моё предположение о том, что ваш шлюз не отвечает на arp-запросы ко второму адресу, отменяется·

тогда я бы предложил зайти с другого конца:
при обращении из внешнего мира по второму public ip вы наблюдаете на интерфейсе ppp0 пакеты, в поле destination у которых стоит этот второй public ip?
если нет — трясите провайдера·
если да — следующий вопрос:
правильно ли ваш шлюз маршрутизирует эти пакеты? например, ping-и на этот public ip, отправленые с вашего шлюза, действительно отправляются вашему второму компьютеру и ответы благополучно возвращаются от него?

[Action]

Конечно, не моё дело, но таки объясните, а зачем так криво? Зачем тогда NAT? Не примите за назойливое поведение, от жтогозависят правиля и цепочки iptables

Суть в том, чтобы обойтись без NAT. В какой-то мере вроде DMZ. Типа сеть для хостинга, в ней у серверов белые IP, но ещё перед ними файрволл, который никак нельзя обойти и наличие которого вряд ли будут ожидать, исxодя из белых IP eго подзащитных.

[Action]

при обращении из внешнего мира по второму public ip вы наблюдаете на интерфейсе ppp0 пакеты, в поле destination у которых стоит этот второй public ip?
если нет — трясите провайдера·
если да — следующий вопрос:
правильно ли ваш шлюз маршрутизирует эти пакеты? например, ping-и на этот public ip, отправленые с вашего шлюза, действительно отправляются вашему второму компьютеру и ответы благополучно возвращаются от него?

По первому вопросу - посмотрю, проверю. По второму - сам шлюз пакеты маршрутизирует нормально. На одной карте - LAN, на другой - алиасы из подсети, никак не пересекающейся с LAN, пинг на любые алиасы на этой карте проходит без проблем. Пинги со шлюза на public IP сервера за ним тоже проходят нормально, совершенно без проблем. Скорее всего,опять у провайдера что-то, с ним и раньше проблемы бывали.

[sash-kan]

На одной карте - LAN, на другой - алиасы из подсети, никак не пересекающейся с LAN, пинг на любые алиасы на этой карте проходит без проблем.

не понял, про какие alias-ы речь· у вас там что, debian gnu/kfreebsd, что ли?
если имеются в виду всё-таки ip-адреса, то тоже не совсем ясно: у вас что, за одним из ethernet-интерфейсов шлюза закреплены два ваших public ip?
какой же адрес вы получаете от провайдера на интерфейсе ppp0?
из вашего рассказа я понял, что должны получать первый public ip·
второй же public ip должен быть закреплён за ethernet-интерфейсом второго компьютера, а на ethernet-интерфейсе шлюза, соединённом со вторым компьютером (допустим, eth1) должен быть маршрут вида:
$ sudo ip r a <второй public ip> dev eth1

[Action]

sash-kan, вы правильно поняли. У меня не kfreebsd, а Linux. Debian Linux. Может, я терминологию неправильно употребил. Попробую по-другому сказать: если на интерфейсе, к которому _не_ подключена LAN, создать дополнительные адреса, типа ethx:y, то независимо от того, какие это адреса, хоть 1.2.3.4, пинг от второго компьютера идёт на них без проблем. Насколько я понял из man'ов Линукса, "это" (ethx:y) и есть алиасы. При пинге адресов в Интернете со второго компьютера ("белый" IP) без masquerading, но с FORWARD -j ACCEPT на первом tcpdump на интерфейсе ppp0 (Интернет) показывает уxодящие пакеты (icmp request от второго компьюутера), но не показывает возвращающихся (icmp reply). Как я понял из ваших объяснений, это должно означать, что все проблемы у провайдера из-за коряво настроенной им маршрутизации.
При пинге со второго компьютера с masquerading на первом tcp dump -i ppp0 показывает и уходящие, и возвращающиеся пакеты.
Короче, во всём виноват провайдер.
Спасибо всем, кто пытался помочь, думаю, вопрос можно считать решённым.

[sash-kan]

Может, я терминологию неправильно употребил.

правильно, но это терминология из древних unix-ов (и, как ни удивительно, из вполне современных bsd-ей)·
когда-то очень-очень давно разработчиками сетевой системы unix-а была допущена досадная архитектурная ошибка: они не подумали, что у одного сетевого интерфейса может быть несколько ip-адресов· и жёстко увязали сетевой интерфейс с _одним_ ip-адресом·
впоследствии, вместо того, чтобы это недоразумение исправить, был придуман костыль под названием «network alias»·
в linux тоже на первых порах было точно так же — через костыль·
пока в 2000-м году силами нашего соотечественника Алексея Кузнецова сетевая подсистема linux не была кардинально переписана·
и с версии linux 2.0 костыли уже не требуются — можно закреплять сколько угодно ip-адресов за сетевым интерфейсом·
программа ifconfig не менялась, она ничего «не знает» о том, как обстоят дела на самом деле·
взамен ей была написана программа /sbin/ip (из пакета iproute) — вот она-то «всё знает» и «всё понимает»·
претерпела изменения также и работа с маршрутами· в частности, теперь в linux существует несколько таблиц маршрутизации (и можно добавлять новые)·
программа route (из того же «мира», что и ifconfig) тоже «ничего не знает» об этих изменениях·
заменой ей служит всё та же универсальная программа /sbin/ip·
информация об ip-адресах:
$ /sbin/ip a
информация об интерфейсах:
$ /sbin/ip l
информация о маршрутах в таблице маршрутизации main:
$ /sbin/ip r
информация об arp-кэше:
$ /sbin/ip n
дополнительное чтение: man ip

p.s. переработка сетевой подсистемы, естественно, коснулась не только двух частных и мелких вещей, таких, как «одни адрес на один интерфейс» и «одна таблица маршрутизации на всё», изменений много, но, к сожалению, чётко и всеобъемлюще они, afaik, нигде не освещены·

При пинге адресов в Интернете со второго компьютера ("белый" IP) без masquerading, но с FORWARD -j ACCEPT на первом tcpdump на интерфейсе ppp0 (Интернет) показывает уxодящие пакеты (icmp request от второго компьюутера), но не показывает возвращающихся (icmp reply). Как я понял из ваших объяснений, это должно означать, что все проблемы у провайдера из-за коряво настроенной им маршрутизации.

что именно у него неправильно настроено — известно только провайдеру· удачи в разборках с ним·

[Action]

Может, я терминологию неправильно употребил.

правильно, но это терминология из древних unix-ов (и, как ни удивительно, из вполне современных bsd-ей)·

Хотя в наше время приннято всё подряд спрашивать на форумов ("своих мозгов не надо - другие подскажут"), я неследую этой моде и задаю вопросы, как тот, что обсуждался в текущей теме, только в крайнем случае, когда по-другому никак. В остальном же мне видится более осмысленным и целесообразным решать все проблемы самостоятельно, при помощи документации. Одним из источников более-менее серьёзной информации для меня является каталог /usr/share/doc/HOWTO/en-txt. Возможно, поэтому моя терминология несколько отстала от времени.

что именно у него неправильно настроено — известно только провайдеру· удачи в разборках с ним·

Премного благодарен.