Настройка интерфейса с "белым" ip адресом и шлюзом из частных подсетей [решено]

[ksa]

Провайдер выделил "белый" внешний адрес, шлюз же остался прежним (из диапазона частной подсети 10.0.0.0/16). Настройка в винде хр проблем не вызывает - интернет работает. При попытке поднять интерфейс на домашнем сервере-роутере с такими же, прописанными в файле ipv4address, параметрами как и в хр интерфейс поднимается, но с руганью (смена маски результат не изменяет). А результат получаю такой - пинг шлюза выдает "сеть недоступна", а результат пинга, например, ya.ru -- "неизвестный хост". Как можно и как правильно настроить интерфейс при таких параметрах (айпи выделенный "белый", ip шлюза из диапазона частных подсетей) ?
PS До этого был тоже выделенный айпишник, но из диапазона частной подсети. Этот айпишник, собственно, остался за мной, но авторизация сейчас идёт по "белому" ip адресу.

[flint1975]

А если вручную прописать маршрут по умолчанию на 10.0.0.X
и этому интерфейсу назначить второй адрес из диапазона 10.0.0.0/16?
Но тем не менее это костыль!
А какую маску оператор выдал для белого адреса?

[ksa]

С этим костылем работает тоже странно. С внешки веб-сервер откликается, джаббер-клиент к серверу цепляется, видит локальные контакты этого сервера и один контакт с другого сервера (или вообще ни одного). При этом в соединениях я не вижу ни одного исходящего соединения, инициированного какой-либо службой на сервере (это подтверждается состоянием транспортов - они не подключены к соответсвующим серверам, попытка подключить вручную ничего не дает).
Оператор предложил /16. Именно с такой маской подключаются обычные дом. пользователи, сидящие под оффтопиком. Но провайдер при этом добавляет, что должно работать и с маской /8, которую для этого "белого" адреса автоматом дает оффтопик.
PS При этом под оффтопиком интернет работает и с один прописанным "белым" ip при отсутствии второго (внутреннего).

[ksa]

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

[ksa]

Сегодня с утра посетила мысль, что можно попробовать в mangle менять постоянный внутренний айпишник на постоянный "белый" с сохранением "двоевластия" на интерфейсе. К тому же старый внутренний айпишник может пригодиться для локальной сетки прова. Как думают участники, сработает вариант с подменой адресов посредством iptables ? (пока на работе, проверить смогу только ближе к вечеру)

[flint1975]

Оператор предложил /16. Именно с такой маской подключаются обычные дом. пользователи, сидящие под оффтопиком. Но провайдер при этом добавляет, что должно работать и с маской /8, которую для этого "белого" адреса автоматом дает оффтопик.

Странно, они не имеют права давать маску, выходящую за пределы их подсети, а я сильно сомневаюсь что они владеют такой подсеткой /16 тем более /8.
А это может означать, что они сами там nat-ят все по хитрому!

[ksa]

Оператор предложил /16. Именно с такой маской подключаются обычные дом. пользователи, сидящие под оффтопиком. Но провайдер при этом добавляет, что должно работать и с маской /8, которую для этого "белого" адреса автоматом дает оффтопик.

Странно, они не имеют права давать маску, выходящую за пределы их подсети, а я сильно сомневаюсь что они владеют такой подсеткой /16 тем более /8.
А это может означать, что они сами там nat-ят все по хитрому!

Натят или маршрутизируют - ото мне неведомо. Но я точно знаю, что весь трафик от юзеров идет через некий девайс\тазик, который считает трафик (и занимается маршрутизацией). Провайдер небольшой, частный.
После обдумывания пришел к выводу, что второй адрес придется оставить, ведь необходимо, чтобы шлюз был в какой-либо подсети вместе с внешним интерфейсом сервера, смотрящим в Интернет. Наверное "белый" айпишник придется сделать единственным в своей подсети, чтобы механизм отправки пакетов в другие подсети, отличные от частной сети провайдера, работал нормально. Осталось решить проблему подстановки для исходящего с интерфейса пакета (скорее всего в postrouting, правда еще не смотрел, можно ли в этой цепочке менять src адрес) частного адреса источника на "белый".
Такие вот размышления...

[ksa]

Пока ковырял проблему, разобрался, как правильно сделать альяс для интерфейса [etcnet мощно-гибкая штука оказывается :)]. Для начала попробую решить маршрутами, если же не выйдет, то последнее средство потрошить пакет и менять адрес назначения на "белый" перед уходом пакета с сервера.

[ksa]

Таки проблема решена :)
Выкладываю решение. Собственно, о нём я уже тут писал в общих словах.

Итак, имеем белый айпишник, имеем шлюз из диапазона частных сетей (типа 10.0.0.0/16 или 192.168.0.0/16), также у нас есть внутрисетевой присвоенный нам айпишник. Настройка интерфейса, смотрящего в Интернет, проста и понятна. Прописываем два айпишника в файле ipv4address, причем для белого я маску взял /32 (чтобы не плодить теоретически возможный броадкаст с нашего пк). Затем прописываем шлюз в файле ipv4route и выданные провайдером днсы в файле resolv.conf. А теперь добавляем к правилам фаерволла такое (предположим, что у нас айпишник 10.0.1.20, второй белый пусть будет 85.192.x.y, а настроечные файлы интерфейса располагаются в каталоге /etc/net/ifaces/eth1)

Код: [Выделить]

iptables -t nat -A POSTROUTING -o eth1 -s 10.0.1.20 ! -d 10.0.0.0/16 -j SNAT --to-source 85.192.x.yТеперь с исходящими с сервера соединениями в интернет проблем нет.

PS Решение костыльное, конечно, но что поделать, если провайдер по-другому не может вывести тебя в Интернет с белым ip.