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