bgp+nat+2 uplink

Где конфиг BGP?

Эмм.. на что-то влияет???
Готов в личку.
По факту: анонс себя, и сбор с других.
По сути есть интерфейсы с маршрутами, но их два (или более)...
Не пойму куда нат пихать.

Мысль тупит на моменте: есть нат и обычное правило:
-A POSTROUTING -s x.x.x.x/y -o iface -j SNAT --to-source z.z.z.z
но т.к. интерфейсов 2 или более - что указывать в качестве iface?

A POSTROUTING -s x.x.x.x/y ! -o local_iface -j SNAT --to-source z.z.z.z

- натить на отдельном железе до бордера

- выдавать real ip на интерфейс

Поднять lo/tun/или-как-ещё интерфейс адресом из автономки /32 и натить через него. Nеtfilter осилит?

«натить на отдельном железе до бордера» - прекрасный вариант, но нет железки.
«выдавать real ip на интерфейс» - на какой???
«A POSTROUTING -s x.x.x.x/y ! -o local_iface -j SNAT --to-source z.z.z.z» - мысль хорошая, но над поднимать на каком либо интерфейсе этот самый z.z.z.z, а т.к. интерфейс получается локальный (пробовал ifb, dummy) - то пакеты как-то пробигают мимо цепочки nat/POSTROUTING...
Работать начинает если поднять z.z.z.z на одном из аплинков, но как тогда реализовать работу с двумя аплинками?

> «A POSTROUTING -s x.x.x.x/y ! -o local_iface -j SNAT --to-source z.z.z.z»

1. бывает не только SNAT. Есть ещё MASQUERADE. Замечательно работает.
2. SNAT тоже вполне работает от IP на lo.

> Работать начинает если поднять z.z.z.z на одном из аплинков, но как тогда реализовать работу с двумя аплинками?

А разьве не работает ? С чего бы ? Тут засада только одна: будут проблемы, если интерфейс ляжет, который с этим z.z.z.z/32. В общем, поднимай на lo алиасом.

Решено!
Просто не надо поднимать адреса нигде.
«Linux и не будет его маршрутизировать, т.к. IP-адрес назначения в ответах сначала пройдёт через обратный NAT в postrouting'e, превратится в приватный, и уже после этого попадёт в маршрутизацию.»
ну и +
«A POSTROUTING -s x.x.x.x/y ! -o local_iface -j SNAT --to-source z.z.z.z»

MASQUERADE плохая идея в этом случае

> Просто не надо поднимать адреса нигде.

Это неправильный путь

IP-адрес назначения в ответах сначала пройдёт через обратный NAT в postrouting'e

Только пакету надо как-то ещё дойти до шлюза с NAT. В данном частном случае, когда BGP на нём де и пакеты снаружи на него попадают так или иначе, оно будет работать, видимо. Но на универсальное решение это не тянет. не ленись, подними IP на lo. :-) Однажды, в будущем, жизнь может проще оказаться.

> MASQUERADE плохая идея в этом случае

С учётом того, что внешние каналы на операторских IP скорее всего, наверное да, не очень хорошо.

При поднятии интерфейсов на ifb|dummy|lo перестаёт работать нат для поднятого ip хотя ip виден из инета.

> При поднятии интерфейсов на ifb|dummy|lo перестаёт работать нат для поднятого ip хотя ip виден из инета.

А почему у меня это работает ? :-) Что-то не так делаешь. Надо посмотреть внимательно.

При поднятии интерфейса - трафик переставал бегать через NAT-POSTROUTING, с чем связано - ума не приложу...

строку с "! -o local_iface" надо, наверное, заменить на две, с -o eth0, и -o eth1. Не надо snat на lo вешать...

Кстати, вопрос не в тему. BGP кто ? Quagga ? Если Quagga, то какая версия, и работает ли «bgpd -C», когда bgpd работает ?

Quagga. К ней вопросов нет - работает в идеале.
«строку с »! -o local_iface" надо, наверное, заменить на две, с -o eth0, и -o eth1. Не надо snat на lo вешать"
дык с lo он и не работает.
а какой вариант с ! или без - думается что монопенисуально.

> Quagga. К ней вопросов нет - работает в идеале.

Я же уточнил, что вопрос по другому поводу. Проверка конфига у bgpd (bgpd -C) работает, когда демон запущен, или нет ?

дык с lo он и не работает.

а какой вариант с ! или без - думается что монопенисуально.

Вот если идёт условие вида "! -o eth3", это означает, что для трафика, исходящего с других интерфейсов, а том числе с lo, правило с SNAT срабатывает. Можно ещё просто попробовать первым правилом сделать

A POSTROUTING -o lo -j ACCEPT

при запущеном демоне - Аварийный останов (сам демон продолжает работать).
при остановленом - ничего не выдаёт.

с lo не работало ни при каких вариантах, такое ощущение что работа с натом требует наличия физ. карт.

> при запущеном демоне - Аварийный останов (сам демон продолжает

работать). при остановленом - ничего не выдаёт.

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

с lo не работало ни при каких вариантах, такое ощущение что работа с натом требует наличия физ. карт.

У меня однозначно работает. Есть, даже, вариант, когда на lo несколько разных ip под SNAT висит.

дык сам удивляюсь - не менялись счётчики в iptables nat при попытке поднять адреса на lo | dummy | ifb ...

Зачем извраты с lo ? Все прекрасно работает и без этого, главное чтоб трафик проходил через этот роутер в обе стороны

Насколько я понял, ТС использует эту сеть только для ната и не выдает реал ип на интерфейс.

Анонсишь сеть и в конфиге quagga заворачиваешь ее в null

Писать -o eth0, -o eth1 нет смысла, т.к. всего 3 интерфейса серез которые идет трафик

! -o local_if спасает от глюков в случае проблем с маршрутами во втутенней сети.

> Писать -o eth0, -o eth1 нет смысла, т.к. всего 3 интерфейса серез которые идет трафик

Четыре. Ещё lo. И вот там NAT может оказаться вреден временами. Лучще его сразу каким-либо образом исключать. Я как-то раз на что-то наступил из-за этого, с тех пор сразу сейчас строю правила так, чтобы lo не затрагивался, если я этого специально не делаю.

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