сетевой интерфейс по умолчанию

ip route change default via 79.111.160.1 src <нужный_адрес>

Это для самого сервера, для маршрутизации твоих внутренних подсетей используй SNAT, ибо назначай адреса из белой подсети вручную. В этом случае надо использовать адреса 57-62, причем один из них (57) уйдет на шлюз.

s/ ибо / либо /

внутри сети все работает. нужно именно на сервере. сделал - теперь подозреваю что что-то еще не хватает. ибо

root@server:/etc/ppp# ip route change default via 79.111.160.1 src 79.120.66.57

root@server:/etc/ppp# tracepath 213.180.193.3
 1?: [LOCALHOST]                                         pmtu 1500
 1:  no reply

Провайдер выдал тебе подсеть белых адресов?

да. 29 только, но подсеть.

правда я ее не использую

Ну так и воткни всю сеть в свитч и назначь на нее белые айпишники + провайдерский шлюз.

А можно глянуть на tcpdump в момент, когда ты запускаешь tracepath?

Провайдер, возможно, маршрутизирует эту подсеть через его адрес на внешнем интерфейсе.

НАТить пачку белых адресов в один - это как-то глупо. Или я не совсем понял, о чем ты.

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

У прова маршрут до этой /29 подсети прописан через его другой белый адрес. В итоге это все может работать без ната.

tcpdump -ni eth_nbn

оказалось несколько все интереснее

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

ppp0      Link encap:Point-to-Point Protocol
          inet addr:176.193.205.75  P-t-P:212.1.254.122  Mask:255.255.255.255

root@server:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         212.1.254.122   0.0.0.0         UG    0      0        0 ppp0
79.111.160.0    0.0.0.0         255.255.224.0   U     0      0        0 eth_nbn
79.120.66.56    0.0.0.0         255.255.255.248 U     0      0        0 eth_int
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth_int
212.1.254.122   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

а я обрадовался, что могу выкинуть pppoe

Ну тогда первый внешний айпишник из диапазона - на внутреннюю сетевуху, этот же адрес всем остальным назначить шлюзом, а на «сервере» найти и убить забытое правило SNAT|MASQUERADE.

теперь я в непонятках, как прописать правило для snat

сейчас так:

-A POSTROUTING -s 192.168.1.0/24 -o eth_nbn -j MASQUERADE

а я хочу, чтоб наружу они светились по другому. но смущает меня писать -o eth_int, -o ppp0 тоже не дает желаемого результата

проблема то была еще до nat. Для этих адресов nat не использовался

У тебя что, проблема только на одной машине, которая с двумя сетевухами?

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

сейчас следом подтянулась другая проблема

но все это косметика, трафик то и без этого ходит

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

Для адресов из /29 подсети нат не нужно делать, для маскарадинга 192.168.1.0/24 можно использовать либо адрес на ppp0 интерфейсе (т.е., iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp0 -j MASQUERADE), либо любой незанятый адрес из /29 подсети (-j SNAT --to <адрес> вместо MASQUERADE). Для самого сервера можно сделать ip route change default via 212.1.254.122 src что.то.там.57, должно работать по идее.

Это адрес /29 подсети, он не принадлежит ни одной машине.

подтянулась другая проблема

Судя по тому, что я вижу, не подтянулась вторая проблема, а решилась первая.
Делай внутреннюю сеть 192.168.0.0 и НАТь сквозь шлюз каждую тачку в отдельный адрес из сети 79.120.66.56/29, т.е. не маскарад «много-в-один», а честный SNAT 1:1. Еще и адрес сэкономишь, который у тебя сейчас на внутреннем интерфейсе сервера пропадает зря, а с самого сервака локальный трафик пусть ходит как ему нравится.

на с ip сервера все получлось, на этом спасибо

А для SNAT я ip сервера не смогу использовать? чтоб не тратить еще один ip адрес?

и правильно понимаю, что MASQUERADE сам определяет, какой ip подставить, поэтому не получиться сделать произвольный адрес

Еще и адрес сэкономишь

Даже не один адрес, а целых три, кстати, т.к. можно брать .56 и .63

в смысле подтянулось - это захотелось решить еще одну

не, честный мне не надо. Для серых ip я готов использовать snat обычный

А для SNAT я ip сервера не смогу использовать? чтоб не тратить еще один ip адрес?

Если не планируешь его использовать для доступа к серверу из интернета, то можешь, ничего страшного вроде не должно произойти.

и правильно понимаю, что MASQUERADE сам определяет, какой ip подставить, поэтому не получиться сделать произвольный адрес

Оно подставляет адрес интерфейса, через который уходит трафик

Для серых ip я готов использовать snat обычный

Я о том, что в моем примере часть серых (192.168.0.[2-7]) ты «обеляешь» SNAT'ом в [79.120.66.57-62] и имеешь таким образом свою белую сеть /29, а остальную часть маскарадишь адресом eth_nbn.

Ну а вообще как хочешь, конечно.

Если не планируешь его использовать для доступа к серверу из интернета, то можешь, ничего страшного вроде не должно произойти.

планирую. Но если я не прав, то поправь меня. snat работает так: * приходит пакет из внутренней сети * ему подменяется ip, отправляется дальше, делается запись в таблице * обратную операцию делают только для соединений, для которых есть запись в таблице

то есть входящие соединения на это не должны ни как реагировать

то есть входящие соединения на это не должны ни как реагировать

Да, ты прав. Похоже, я излишне перестраховывался %)

еще один вопрос

*nat
:POSTROUTING ACCEPT [16:1181]
-A POSTROUTING -d 212.1.224.74/32 -o tun2 -j MASQUERADE
-A POSTROUTING -d 212.1.224.74/32 -o tun2 -j ACCEPT
-A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 79.120.66.57
COMMIT

Правильно я понимаю, что я переправляю запросы на 212.1.224.74 на интерфейс tun2 ? а то они похоже продолжают ходить через моего провайдера

Если это адрес на сервере, то ты не можешь контролировать, как к тебе приходят запросы. Если это не твой адрес, то надо изменять не правила iptables, а таблицу маршрутизации. Т.е. ip route add <этот_аддр> dev tun2

это не мой адрес Важно, я хочу, чтоб через tun2 мог ходить не только сервер, но и клиенты за ним, с реальными или серыми ip

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

Шо за бред? Тот же провайдер, такая же услуга с сетью /29, никаких PPPoE.

Или я не правильно настроил, или у нас разные настройки со стороны провайдера

Настройка требуется ровно никакая.

Что бы выкинуть ppp, обратитесь в техподдержку, они повесят триггер с роутом на свой dhcp.

А у меня к Вам вопрос: они до сих пор дают такие сети? Сейчас такого не нашёл.

Сейчас вообще отбирают такие. И не дают, даже своим.

Все зависит от района и оборудование. Кому-то можно, кому-то нет. Но особо не важно, pppoe не требователен, а обычный интерфейс я заблокировал.