проброс всех соединений

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

но зачем? мне выделена целая подсеть и адресами внутри неё я могу распоряжаться как хочу

А недостаточно машинам за NAT'ом выдать внешние адреса и включить форвардинг?

достаточно, думаю. только как это делается, не знаю. не нагуглил

как это делается, не знаю

Что именно? Включение форвардинга в дебиане/убунте делается примерно так

sysctl -w net.ipv4.conf.all.forwarding=1

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

тот, через который он к локалке подключен, имеет локальный адрес

Что мешает поставить внешний?

на два интерфейса один и тот же, например?

Разные. Например, на интерфейсе, смотрящем в интернеты 34.56.78.1, а на смотрящем в локальную сеть - 34.56.78.2, клиентам шлюз, соответственно, 34.56.78.2.

ладно, можно потратить ещё один айпи, например. это нормально сочетается с уже настроенной локальной подсетью в диапазоне 10.0.0.0/8 и шлюзом из этого же диапазона на том же интерфейсе? экспериментировать не хочется

Да, должно быть нормально.

VLAN ом делается... Что за мода такие вопросы задавать на ЛОРе в последнее время?

а по русски?

для влана я недостаточно прохаван

А как вы думаете будут попадать на ваш шлюз, у которого наружу адрес с одним внешним IP, пакеты, адресованные дргум IP адресам ?

Вот блин, я об этом и не подумал. У меня ведь провайдер предоставляет маршрут к выделенной подсети через адрес шлюза.
Прошу прощения у ТС за дезинформацию.

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

тащемта у меня то же самое. и именно это я пытался донести во втором сообщении с начала темы

Я не знаю что вы там сделали с виртуалками. Но если у вас наружу один IP адрес, то вот вы мне опишите, как клиент с наружи догадается, что ему надо отправлять пакеты на этот адрес, что бы достучаться до дргуого IP адреса.

man nat. Либо промаршрутизируй внешку внутрь.

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

Я не знаю как ещё вам объяснить.

проброс всех соединений (комментарий)

я уже сказал, что мне выделена подсеть, а не конкретный адрес

всё по делу, да только об этом я и сам догадался

если вы подключаете один ПК и выставляете ему определённый IP из этого диапазона

в чём разница между выставлением конкретного айпи и проброса с него пакетов и выставлением ему нескольких айпи и отправки, с задействованием ната всех пакетов, присланных на конкретный внешний айпи на некий иной локальный айпи? если есть разница, то лично я подразумевал нечто описанное во второй части

Если эти адреса провайдером выданы как подсеть на сегмент ethernet, без маршрутизации через ваш шлюз, то либо прописывать все эти адреса на внешний интерфейс и делать DNAT-правила в iptables, либо создавать для провайдера видимость, что эти адреса пренадлежат вашему серверу (через proxy-arp или ″ip neigh add proxy″) и маршрутизировать их в локалку.

Вначале рекомендую детально разобраться в том, как работает IP-маршрутизация/адресация в ethenet сети.

пакеты, адресованные IP адресам, которые не подключены к сети провайдера

вот это профукал. вообще-то я не говорил, что диапазоны разные. все адреса из одной подсети и подключены к сети провайдера

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

proxy arp это не оно?

Если мне память не изменяет провайдер может выдать сетку любую, но тут есть «но»

1. Он может выдать ip которые могут быть в этой сети (во всей сети будут указан их шлюз), для этого и нужен proxy arp

2. Он может сделать чтоб вы сами могли маршрутизировать эти ip (Когда у вас один из ip будет шлюзом всех остальных вышей сети)

Хотя могу ошибаться!

Йопт... Значит iptables крутить для тебя херня вопрос, а в свитче мышкой потыркать в GUI нереал)))?

статические arp-ы решают

а разве у цисок есть толковый гуй?

Ну ты не говорил про циску ничего. Нет, гуя толкового нету. :( Но всё же VLAN это стандартное решение которое должно применяться в этом случае. А если сервера рядом - то вообще ничего не надо, просто свитч обычный. А вот iptables - это даже не идиотизм... А маразм в этом случае. :)

ну мне проще работать с известными технологиями, а так первым делом про это и подумал. ну может и потыкаю

Если локалка использует внутренние адреса, то вообще похорошему счёту никто не мешает воткнуть в обычный любой свитч и настроить на нужных компах нужные адреса. - Не безопасно, но и не смертельно.

Провайдер всё одно - со внутренними адресами никуда не выпустит, и с внутренних адресов ничего не впустит.

никто не мешает воткнуть в обычный любой свитч и настроить на нужных компах нужные адреса

я б так и сделал, да только от принимающего интернет свитча нужные устройства находятся далеко

а сбриджевать нельзя? у меня на роутере настроен nat, wan-интерфейс получает ip по dhcp от isp. Дополнительно wan сбриджеван с wifi-интерфейсом, клиенты wifi получют свои ip-адреса по dhcp от isp.

с помощью чего это делается?

http://xgu.ru/wiki/man:brctl для одного сегмента ethernet. а у тебя вроде его нету?

есть, у меня везде коммутаторы, а не маршрутизаторы

можно либо поднять дополнительные айпи на роутере и настроить статический нат (DNAT)

либо arp-proxy

решено: http://unixforum.org/index.php?showtopic=118633#entry1107123