Добрый день!Подскажите начинающему linux-любителю..
Не пойму как почистить NAT (и другие) трансляции в iptables/netfilter, те, которые в выводе cat /proc/net/nf_conntrack
Есть ли что похожее на cle ip nat translations * (cisco), или pfctl -F state (pf) ??Это мне нужно при переключнии default gateway на второго ISP при отработке ситуции отказа основного провайдра и переходе на резевного
Т.е. раутер(шлюз) раздающий инет подключен к двум ISP.Получается что когда 1й провайдер сдох, гейтвей переключился на второго, но в cat /proc/net/nf_conntrack отстались записи связянные со сдохшим каналом 1го провайдера. И у машины в локальной сети в этом случае нет доступа к недавно использовавашимя ресурсам инета...
Использую openSUSE 11.2 (kernel 2.6.31.5-0.1-desktop)
iptables v1.4.4Что то у меня нехорошее предчувствие после гугления этой темы... неужеле нельзя просто командой какойто?
PS.
Провайдеров переключаю пингующим скриптом.
Может есть альтернативный, более грамотный, элегантный, "промышленный" подход к этому делу в Linux?
> Не пойму как почистить NAT (и другие) трансляции в iptables/netfilter, те, которые
> в выводе cat /proc/net/nf_conntrackconntrack-tools, наверное....
>> Не пойму как почистить NAT (и другие) трансляции в iptables/netfilter, те, которые
>> в выводе cat /proc/net/nf_conntrack
> conntrack-tools, наверное....Да, имеено оно, спасибо!
> Что то у меня нехорошее предчувствие после гугления этой темы... неужеле нельзя
> просто командой какойто?можно
# conntrack -F
conntrack v0.9.14 (conntrack-tools): connection tracking table has been emptied.> PS.
> Провайдеров переключаю пингующим скриптом.
> Может есть альтернативный, более грамотный, элегантный, "промышленный" подход к этому
> делу в Linux?BGP, но дорого :)
З.Ы.
при переключении также рекомендую выполнять ip ro flush cache и уменьшить значение /proc/sys/net/ipv4/route/gc_timeout
>[оверквотинг удален]
> # conntrack -F
> conntrack v0.9.14 (conntrack-tools): connection tracking table has been emptied.
>> PS.
>> Провайдеров переключаю пингующим скриптом.
>> Может есть альтернативный, более грамотный, элегантный, "промышленный" подход к этому
>> делу в Linux?
> BGP, но дорого :)
> З.Ы.
> при переключении также рекомендую выполнять ip ro flush cache и уменьшить значение
> /proc/sys/net/ipv4/route/Вроде с первого взгляда заработало как хотел...
Насчет gc_timeout ценный совет, вероятно уберегло от всяких "загадочных глюков" :). Премного благодарен!
> PS.
> Провайдеров переключаю пингующим скриптом.
> Может есть альтернативный, более грамотный, элегантный, "промышленный" подход к этому
> делу в Linux?а как к провайдерам подключаетесь?
>> PS.
>> Провайдеров переключаю пингующим скриптом.
>> Может есть альтернативный, более грамотный, элегантный, "промышленный" подход к этому
>> делу в Linux?
> а как к провайдерам подключаетесь?Статическими IP.
Хотя вопрос наталкивет на интересные мысли о динамическом PPPoE...
на полигоне надо бы обкатать это.Как я понимаю, в этом случае
натить лок. сеть в инет МАСКАРАДОМ:
iptables -t nat -A POSTROUTING -s 1.1.1.0/24 -o ppp0 -p ALL -j MASQUERADEПроброс порта как то так:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 8080 -j DNAT --to-destination 1.1.1.10:80Вроде подводных камней не должно быть?
Или что то не учел в размышлениях, как по вашему?
>[оверквотинг удален]
> на полигоне надо бы обкатать это.
> Как я понимаю, в этом случае
> натить лок. сеть в инет МАСКАРАДОМ:
> iptables -t nat -A POSTROUTING -s 1.1.1.0/24 -o ppp0 -p ALL -j
> MASQUERADE
> Проброс порта как то так:
> iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 8080 -j
> DNAT --to-destination 1.1.1.10:80
> Вроде подводных камней не должно быть?
> Или что то не учел в размышлениях, как по вашему?- по барабану ч/з чего адреса пробрасывать. что ч/з маскарад, что ч/з нат. я предпочитаю нат. обычно пару лишних телодвижений при подключении к прову с динамическим ИП сделать надо (но это разовая работа), зато потом ИМХО работает быстрее и меньше ресурсов жрет.
- в правилах iptables можно указать интерфейс ppp+, что будет соответствовать всем ppp-интерфейсам.
- для ppp можно указать номер интерфейса, который будет использоваться при исходящем соединении (опция unit). помогает, когда ты к себе клиентов по ppp подключаешь и к провайдеру тоже по ppp. тогда, скажем при наличии 50-ти собственных клиентов, для подключения к прову даешь опцию unit=100 и твой провайдер будет на интерфейсе ppp100 (а для 50-ти твоих клиентов номера интерфейсов явно будут ниже при подключении). обычно здесь засада - все спрашивают как назначить номер ppp-интерфейса своему клиенту (чтобы по ppp0 я к прову, а клиент-злыдень занял уже ppp0...), а на самом деле этого и не надо.
- исходя из вышесказанного: ты всегда будешь знать номер интерфейса к прову и сможешь обработать его в скриптах поднятия/отключения интерфейсов.
- если используешь нат, то в скрипте поднятия интерфейса к прову (ты же уже знаешь его номер), видимо придется перезапустить локальный ДНС-сервер и подобные сервисы (если они есть), чтобы они смогли привязаться к поднятому интерфейсу и слушать на его ИП.
ну вроде больше ничего сходу посоветовать не могу на счет динамического ИП от прова.
> Вроде подводных камней не должно быть?
> Или что то не учел в размышлениях, как по вашему?есть, надо использовать -j CONNMARK --save-mark/--restore-mark либо ctorigdst (более предпочтительно)