Poate ca nu m-am facut inteles , asa ca o sa incerc sa ma exprim mai clar ,
dar mai intai cred ca e cazul pentru o mica precizare : in documentul pe
care ni l-a indicat Wolfy exista urmatorul paragraf :
"
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
This set of commands makes sure all answers to traffic coming in on a
particular interface get answered from that interface. "
Din cate imi dau eu seama, asta inseamna ca traficul catre $IP1 se va
intoarce prin $IF1 si traficul care vine catre $IP2 se intoarce prin $IF2 .
Pina aici toate bune si frumoase, numai ca pe mine nu asta ma intereseaza .
In primul mesaj am spus ca prin toate interfetele de pe masina mea vine
trafic catre ACEEASI adresa ip ( sa zicem $IP1 ) . Evident ca solutia de
mai sus va face ca traficul generat de $IP1 ca raspuns la cererile venite de
oriunde vor pleca urma regula "ip rule add from $IP1 table T1" si vor iesi
prin gateway-ul specificat in tabela T1 .
Iata si exemplul meu :
Am un server de DNS si un server Web . Serverul DNS este modificat , astfel
incat pentru zona www.domeniu.com va raspunde diferit in functie de tara
careaia apartine IP-ul care face requestul .
Daca tara=RO , DNS-ul raspunde (sa zicem) cu adresa 192.168.100.1
Daca tara!=RO, DNS-ul raspunde (sa zicem) cu adresa 192.168.200.1
IP-ul 192.168.100.1 este asignat interfetei eth0 pe masina care este si
server de web ( sa-i zicem A ) .
IP-ul 192.168.200.1 este asignat interfetei eth0 pe o masina care nu are
server de web pe el ( sa-i zicem B ).
Odata aflat acest IP, browserul utilizatorului va trimite cererea HTTP catre
unul din cele doua IP-uri .
Intre cele doua masini exista un tunel IPIP , cu capetele 10.0.0.1 pe masina
A si 10.0.0.2 pe masina B.
Pe masina B exista o ruta statica catre IP-ul 192.168.100.1 :
"ip route add 192.168.100.1/32 via 1.1.1.1 dev my_tunnel proto static"
si o regula de DNAT :
"iptables -A PREROUTING -t nat -p tcp --d 192.168.200.1 --dport 80 -j
DNAT --to-destination 192.168.100.1 "
In aceste conditii, un packet cu sursa (sa zicem) 3.3.3.3 care ajunge in
192.168.200.1 pe portul 80 este redirectat prin tunelul my_tunnel catre
192.168.100.1 cu sursa nemodificata ( e foarte important acest aspect - daca
as fi putut ignora acest aspect as fi folosit un proxy transparent , dar
aceasta solutie nu poate intra in calcul )
Problema este ca masina A raspunde intotdeauna urmand ruta default , deci
packetele nu se intorc pe acolo pe unde au venit . Mai mult decat atat,
pachetele vor ajunge la 3.3.3.3 ca venind de la 192.168.200.1 , si nu de la
192.168.100.1 . Evident conexiunea TCP nu poate fi stabilita in aceste
conditii .
Pe de alta parte, daca sursa 3.3.3.3 trimite un paket direct catre
192.168.100.1 , conexiunea poate fi stabilita la nivel TCP si poate fi
initiata sesiunea HTTP .
Cu speranta ca m-am facut cat de cat inteles si ca nu am spus prea multe
tampenii^H^H^Hmesaje, asa cum le place unora sa afirme astept o sugestie de
la voi .
Alex
P.S. Intre timp am gasit o solutie, care nu-mi place insa deloc si care
nu-mi ofera posibilitatea generalizarii acestei aplicatii .
----- Original Message -----
From: "lonely wolf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 15, 2004 10:39 AM
Subject: [rlug] Re: Reverse Path Filtering versus dynamic source routing
> Mihai Rusu wrote:
>
>>On Wed, 15 Dec 2004, Alex Sirbu wrote:
>>
>>
>>
>>>Sa zicem serverul respectiv are adresa IP 1.1.1.1 si asculta pe portul
>>>80 .
>>>Prin toate interfetele de pe masina respectiva pot veni cereri catre
>>>1.1.1.1
>>>, dar neavand reguli statice e clar ca raspunsurile se vor duce prin ruta
>>>default .
>>>
>>>
>>
>>Si ai default gateway pe ambele interfete ? (adica un ruter pe fiecare din
>>interfete in stare sa iti poata ruta trafic oriunde in afara?)
>>
>>In caz afirmativ citesti documentatia iproute si configurezi policy
>>routing sa trimiti catre gateway-ul de pe eth0 ce vine prin eth0 si catre
>>gateway-ul de pe eth1 ce vine prin eth1.
>>
>>Asta ca sa raspund direct la intrebare. Otherwise eu tare ma indoiesc ca
>>tu chiar ai nevoie de asa ceva si de fapt e rezultatul unei greseli mai
>>mari care o faci si pe care nu ai expus-o aici.
>>
>>
>>
> lasa-l dizzy, ca el stie ca nu merge dinainte sa citeasca documentatia.
> daca s-ar fi uitat pe linkul dat de mine, nu raspundea cu timpenia^H^H^H
> mesajul cu care a raspuns.
>
> --
> Brain:The apparatus with which we think that we think.
>
>
>
> ---
> Detalii despre listele noastre de mail: http://www.lug.ro/
>
---
Detalii despre listele noastre de mail: http://www.lug.ro/
