dva interface do WAN

Dan Lukes dan at obluda.cz
Sat Feb 6 18:17:03 CET 2010


On 02/06/10 16:36, Zbyněk Burget:
>> Zalezi, jestli jsou ty linky takoveho typu, ze se na nich vypadek pozna.

> Tohle je uvaha spravnym smerem.

Diky.

> Server sam pro svoji cinnost nepotrebuje pripojeni k internetu.

Ale urcite nevadi, ze ho vzdy, pres jednu nebo druhou, linky mit bude.

> Poskytuje nejakou sluzbu klientum, podstatne je, aby ta sluzby byla
> dostupna pokud mozno bez vypadku. V klientovi budou nastaveny dve IP
> adresy. Pokud se mu informaci nepodari ziskat z jedne (posle request,
> nevrati se odpoved), zepta se na druhe IP. Komunikace probiha na TCP
> protokolu.

Takze, predpokladam, ze nevadi, ze jiz zahajena spojeni se v kazdem 
pripade rozpadnou a neni zpusob, jak je zachranit.

> Pokud bude mit server nastavenou default routu do subnetu 1 a prijde mu
> request ze subnetu 2, jak docilit toho, aby i odpoved sla smerem do
> subnetu 2.

Jinymi slovy chces, aby odchozi interface byl zvolen podle zdrojove, 
nikoliv podle cilove adresy.

Ale to by snad mela byt trivialni uloha pro ipfw:

ipfw ... fwd <nexthop1> from <local1> to any out
ipfw ... fwd <nexthop2> from <local2> to any out

Dokonce staci jen jedno, pokud je jeden z nexthopN defaultni nexthop ...

> Resp. pokud ji posle na default gateway a ona nedorazi k cili
> (= nedostane potvrzeni prijeti packetu), aby se server pokusil odpoved
> odeslat znovu pres subnet 2.

Ne, to motas zalezitosti z nesouvisejicich urovni a proto to nepujde. 
Routing, to je zalezitost treti vrstvy (sitova, IP). Nejake potvrzovani, 
to je ctvrta vrstva, (transportni, TCP). Treti vrstva nikdy nic 
nepreposila a ctvrta zas nemuze ovlivnit routing.

A navic i kdyby to slo - bylo by to bylo k nicemu. Pokud nema subnet 1 
konektivitu tak nema nejmensi smysl posilat odpoved pres subnet 2, 
protoze klient bude i nadale komunikovat vyhradne pres subnet 1 - a 
tudiz se stejne nedomluvi.

					Dan



More information about the Users-l mailing list