pats dar prisiminiau kad tik 192.168.5.0 kreipiasi y 192.168.1.0, 192.168.1.0 nelenda pats atgal, taj tiesiog galeciau 192.168.5.0 daryt Masquerade ant 10.0.1.2 y 192.168.1.0, tad serveris A matys paketus kajp is 10.0.1.2 ir todel atsakines per 10.0.1.1. O is serverio B tiesiog NAT'inti per MPLS'a y 192.168.6.253. rabarbaras wrote: > Ruoteriui nusispjaut is kur gavo paketa - jo reikalas zinoti > destination. Tai ka cia sugalvojai gal but imanoma isspresti su > marsrutizavimo protokolais. > Kaip cia supratau MPLS'as pridetas avarijos atveju linkui backupuoti? > Del to nutrukus 10.0.1.0 linkui turetum statiskai pakeisti routinima. > Max ka as esu isgalvojes is tokiu scenariju - 192.168.5.0 ir 192.168.1.0 > tinklus per skirtingus linkus galima apjungti su SourceRouting+NAT. > Pradzia bus http://lartc.org/ > > rycius wrote: >> sveiki, turiu toki galvosuki, atachmente yra prisegta tinklo struktura >> ( tik serveryje A turetu buti IP ne 10.0.1.2 o 10.0.1.1, tiesiog >> bepaisydamas klaida padariau). Is LAN 192.168.5.0/24 yra bendraujama >> su LAN 192.168.1.0/24 per linka 10.0.1.0/30. Bet db prisireike kad LAN >> 192.168.5.0/24 galetu bendrauti per MLPS VPN su 192.168.6.253. >> >> Serveryje B tiesiog padaryta: >> route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.1 >> route add -net 192.168.6.0 netmask 255.255.255.0 gw 192.168.5.253 >> >> Serveryje A: >> route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.0.1.2 >> >> kajp man cia issisukti serveryje A, kadangi jame gaunasi kad >> 192.168.5.0/24 potinkli jis gali pasiekti ir per 10.0.1.2 ir per >> 192.168.6.253. Cia as kajp suprantu, kazkokiu budu reiktu serveriui A >> susigaudyti per kuri linka serveris gavo uzklausa is 192.168.5.0/24 ir >> per ta linka jam atsakyti. Gal kas uzvestumete ant kelio kajp tai >> padaryti? >> >> >> ------------------------------------------------------------------------ >>