Re: lug-bg: Един ping, source routing и два SNAT-а.

[Daniel Ivanov <sertys@xxxxxxxxxxxxxx>]

Да, най-болезнено става с "изваждането на ip_conntrack модула от ядрото 
и слагането му обратно". Предполагам знаеш, че това подлежи на 
dependencies - ipt_MASQUERADE, iptable_nat, ipt_state трябва да са вън 
от кернела също. Това обаче е много болезнено по простите 2 причино - 
първо трябва да махне всичките stateful правила от firewall-a и после 
трябва да сложи или DROP, или REJECT полици на филтер таблцита.
Един cheat за който се сещам е просто да пратиш по един RST пакет на 
връзките в conntrack-a и да очакваш, че от сега нататък всичко ще излиза 
през новия гейт :)
Трети, но доста труден вариант е да се поровиш в нетфилтер листите, 
където видях методи за манипулация на conntrack таблицата и триене на 
записи.
Rossen Antonov wrote:

> Здравейте,
> след много ровене из google, малко питане и безсмислени и 
> безрезултатни проби стигнах до тук.
>
> Имам следната ситуация:
> eth0 - local net (192.168.0.x)
> eth1 - ISP1
> eth2 - ISP2
>
> И на eth1 и на eth2 има пуснат SNAT:
> >> Chain POSTROUTING (policy ACCEPT 223K packets, 19M bytes)
> >> pkts bytes target     prot opt in     out     source               
> destination
> >> 188K   12M SNAT       all  --  any    eth1    anywhere             
> anywhere            to:85.x.x.x
> >>  823 50110 SNAT       all  --  any    eth3    anywhere             
> anywhere            to:10.0.0.51
> На практика IPS2 не се използва изобщо. Всичко минава през IPS1. В 
> определени моменти искам да прекарам един и точно един хост от 
> локалната мрежа да ползва ISP2. За целта използвам policy routing:
> ip rule add from 192.168.0.7 table viphost
> ip route add default via 10.0.0.1 table vipohost
> ip route flush cache
>
> Всичко изглежда нормално, нали?
>
> Но това се случва в реално време и всички работещи сесии от машината 
> 192.168.0.7 започват да излизат от eth2. Особеното е, че те излизат 
> през eth2 SNAT-нати ___със IP адреса на eth1___. Това първоначално ме 
> шокира. В последствие си го обясних с факта, че ядрото естествено 
> следи сесиите и не може просто така да ги промени. След като 
> въпросните сесии умрат, всички нови дошли на тяхно място излизат 
> правилно. Това се отнася като цяло за всички нови сесии.
> Проблемът идва в това, че от 192.168.0.7 работи пинг към yahoo.com 
> например, постоянно. След като пренасоча 192.168.0.7 през eth2 пингът 
> продължава да излиза с адреса на eth1. Спирам го, пускам го, но той 
> продължава да излиза грешно. Едва когато го спра за дълго време, 
> например 10мин., всичко тръгва коректно. А когато пусна пинг към друг 
> хост _след_ прехвърлянето проблеми нямам.
> Има ли някакъв начин да рестартирам всичко, което ядрото помни за 
> даден хост, защото освен проблемите с пинга може да има и други, които 
> аз не съм хванал все още.