transparent tunel dd-WRT-vel?

Szervusztok!

Van ket OpenWRT-t futtato Linksys router, ezekkel kellene megoldani hogy az egyiknek van egy piblikus IP-je, mogotte par gep egy belso halozatban, a masik pedig akarhonnan, NAT mogul letre tudjon hozni egy alagutat, ami a ra kapcsolt gepet (egy eleg!) a masik router subnetjebe teszi.

EoIP-vel sikerult megcsinalnom, es nagyon szepen mukodik, a tavoli gep kap IPt, minden OK, csak NAT mogul ezt nem lehet hasznalni, ehhez ket publikus IP cim kell. :(

PPTP-vel probalkozom mar ket napja, de nem tudom mukodesre birni ugy hogy jo legyen.
Sajnos a tavoli geppel betarcsazas nem mukodik, ami csomagok HW-esen elhagyjak a tavoli gep kartyajat, meg kell erkezzenek a masik oldalon, es vice-versa.
Precision-Time-Protocol-t hasznalo kartyakrol van szo, HW timestamping-gel. Sima PPTP betarcsazos megoldas nem jatszik, mert a kartyanak szuksege van hogy befussanak a csomagok, hogy a timestamp-et legeneralhassa.

Van valakinek valami otlete?
Routereket olyanra flashelhetem amilyenre akarom, a lenyeg hogy egy EoIP-hez hasonlo transparens alagutat kapjak...

Hozzászólások

Nálam vtund fut OpenWRT alatt egy ASUS WL-500Gp routerben, amire a haverom tud felkapcsolódni egy NAT-olt hálóból. Csomagban elérhető az OpenWRT-ben. Futtatható szerver meg kliens módban is.

Nekem sajnos az nem eleg hogy ha csak latjak egymast, muszaj ugyanabban a subnetben lenniuk a gepeknek, multicast uzeneteknek at kell menni...
Ma mar ebbol nem lesz semmi ahogy latom, de holnap remelem sikerul mukodesre birnom!
Esetleg egy OpenVPN config-od ha lenne, azert nagyon halas lennek am :)

PPTP igen egyszeru, en fix jelszavakkal csinaltam eddig, de radiussal sem bonyolult. Ha elmondod hol akadtal el, lehet tudok ra mondani valami okosat.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hopsz, ez az ami nekem nem jo, mert nem a ppp interfesznek kell subnetbol valo IP, hanem a ethX kartyanak.
Kepzeld el ugy hogy egy kabel van a ket gep kozott, amit ki kell valtani egy teljesen transparens alaguttal a ket routerrel.
Ami egyik oldalon rajta van a halon, annak a masik oldalon is meg kell jelennie. Muszaj a specko HW-t elhagynia es ide beerkeznie a csomagoknak tomorites, titkositas, egyebek nelkul, mert csak akkor triggerelik a megfelelo frame-ek a HW timestampelo egyseget.
:(
pptp-vel, routerokat kihagyva mar megcsinaltam egyszer, de akkor jottem ra hogy nem kalacs, nem tudom hasznalni a HW timestamp egyseget, ami nelkul pedig a GPS stack-em nem tud beavatkozni a PTP idejebe...

Oke, szerintem akkor a dolog nem megoldhato, ugyanis barmilyen tunnel eszkoz alapvetoen azt feltetelezi, hogy a rendszer kepes arra, hogy akarmilyen eszkozon at kommunikaljon.

Ezt szerintem vagy egy elerakott routerrel tudod megoldani legkonnyebben, vagy a specko gep ele kell egy masik, aki kibontja a tunnelt, es csak a nativ csomagokat dobalja at ennek a speckonak.

Sajnos openvpn, pptp, es vtund is arra epit, hogy letrehoz egy tunX/pppX eszkozt, es azon keresztul forgalmaz, valamint belovi a routingot, hogy ezek es ezek az iranyok arrafele erhetok el. Semmilyen modon nem tudsz hardveresen transzparens cuccot csinalni, csak ha eleraksz valamit, ami kibontja neked a tunnelt, es a nyers adatfolyammal bombaz teged.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem megy az openvpn.net de szerintem az is egy masik eszkozre (nem ethX-re) kuldi at az adatokat, vagyis az adatok forrasa a programok szamara nem az ethX lesz (nem is lehet) hanem a bridge. Fentebb viszont kifejtetett, hogy ez nem jo.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Kar hogy a dd-wrt szerint van sokkal fontosabb dolga is mint tovabbitani az adatokat, mert nehany csomagot visszatart amig valami nagyon fontos dolgot elintez...
64 bytes from 192.168.245.254: seq=255 ttl=64 time=4.719 ms
64 bytes from 192.168.245.254: seq=256 ttl=64 time=4.655 ms
64 bytes from 192.168.245.254: seq=257 ttl=64 time=4.718 ms
64 bytes from 192.168.245.254: seq=258 ttl=64 time=4.659 ms
64 bytes from 192.168.245.254: seq=259 ttl=64 time=4.860 ms
64 bytes from 192.168.245.254: seq=260 ttl=64 time=4.676 ms
64 bytes from 192.168.245.254: seq=261 ttl=64 time=4.711 ms
64 bytes from 192.168.245.254: seq=262 ttl=64 time=4.652 ms
64 bytes from 192.168.245.254: seq=263 ttl=64 time=4.676 ms
64 bytes from 192.168.245.254: seq=264 ttl=64 time=4.918 ms
64 bytes from 192.168.245.254: seq=265 ttl=64 time=4.871 ms
64 bytes from 192.168.245.254: seq=266 ttl=64 time=4.679 ms
64 bytes from 192.168.245.254: seq=267 ttl=64 time=4.668 ms
64 bytes from 192.168.245.254: seq=268 ttl=64 time=46.053 ms <---- ez a sirba tesz...
64 bytes from 192.168.245.254: seq=269 ttl=64 time=6.146 ms
64 bytes from 192.168.245.254: seq=270 ttl=64 time=4.717 ms
64 bytes from 192.168.245.254: seq=271 ttl=64 time=4.736 ms
64 bytes from 192.168.245.254: seq=272 ttl=64 time=4.656 ms
64 bytes from 192.168.245.254: seq=273 ttl=64 time=4.697 ms
64 bytes from 192.168.245.254: seq=274 ttl=64 time=4.870 ms
64 bytes from 192.168.245.254: seq=275 ttl=64 time=4.715 ms
64 bytes from 192.168.245.254: seq=276 ttl=64 time=4.665 ms