R: Line Redundancy and Reliability

> 1) non fare thread hijacking e' oltremodo fastidioso.

Che significa? ?-)
Se sono l'unico che non ha capito, spiegamelo in PVT ;-)

> 2) presonalmente questi cosi non mi hanno mai ispirato un gran che.
> in pratica fatico abbastanza a capire quali giochini facciano per
> bilanciare le connessioni.
> - non puoi modificare i reply del dns, a meno che tu non tenga le entry
>   con TTL nullo.

Distinguiamo il traffico in USCITA da quello in INGRESSO.
Per il primo, la storia e facile: prendo la connessione e scelgo su che
router instradarla.
Per il secondo, l'apparato funge da DNS server autoritativo per
www.dominio.it (ad es.) e quindi risponde alle query dei client remoti con
l'IP che risiede sul link ottimale.
Ovviamente non e molto affidabile per via di tutti i caching che ci sono in
giro... ma e il solito problema dei bilanciamenti basati su DNS.

> - generalmente non puoi mandare i pacchetti di reply sull'altro link con
>   l'ip originale perche' gli egress-filter del provider dovrebbero
>   cassarti.

questi apparati normalmente restituiscono il pacchetto al router da cui
proviene, in caso di failure di un link allora si incappa nel problema
dell'egress-filter, ma si potrebbe eliminare lavorando col provider affinche
venga tolto o modificato.

> - non puoi mandare le risposte con un ip address diverso perche' e' il
>   tcp-ip a cassarti.

e meno male ^_^

> - puoi proxare l'http inserendo dei redirect, ma va solo con http.

Si, e fattibile ma come dici tu e una soluzione applicativa e devi essere
sicuro che il link a cui punta il client e UP, altrimenti niente redirect.

Ciao!
---
Daniele Besana - ICQ 21963839
IT Virtual Community
www.itvirtualcommunity.net


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List