Sziasztok,
Van egy szerverem, rajta egy olyan szolgáltatás, amit a kliensek SSDP -vel találnak meg. Hogy ez működjön, OpenVPN TAP -al jönnek be az ügyfelek Windows/Linux/MacOS alól, mindenki kap egy saját TAP interfészt, amire az ügyfél tartományából húzok egy IP címet. Azt szeretném, hogy az ügyfelek 1 openvpn tunnel-en bridge-elve behozhassák a teljes LAN-jukat. A probléma pedig ott van, hogy a kliensek LAN -os IP tartományaik ütközhetnek: amikor a kliens bekérdez SSDP -n, akkor a szerver egy unicast választ generál a multicast üzenet feladójának IP címére, de hogy is route -oljam ezt a megfelelő ügyfél tunnel -jébe..? (Az ügyfelet természetesen nem kérhetem a teljes LAN átcímezésére)Odáig jutottam, hogy adott TAP interfészről jövő IP csomagok forrását egy egyedi IP tartományra kéne maszkolni. Igenám, de az Iptables tudtommal a forráscímet csak a POSTROUTING táblában tudja lefordítani, de ha a szolgáltatás helyi, ezen soha nem megy át a csomag. Ötlet, javaslat? Előre is köszi.
- 997 megtekintés
Hozzászólások
Esetleg a forrás routing nem segíthet neked? ip route, ip rule, stb.? Csak ötletelek...konkrét megoldásom nincs...
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy itt routing nem történik, a szerveren egy helyi szolgáltatást szólítanak a kliensek. Nem is tudom, hogy a multicast kérést hogy lehetne route-olni L3-on.
DE. Miközben gondolkodtam azon, hogy mivel lehet route-olni a multicast-ot (ami esetleg be tud iktatni egy NAT-ot), eszembejutott a bridge: a szerveren berakom a juzer TAP interfészét egy bridge-be és bekapcsolom a bridge-nf-call-iptables -t. Ekkor talán meg tudom NAT-olni a csomagokat, mielőtt a szerver kernele helyiként értelmezné.
Ihletet adtál aminek most utána is járok, köszi! :)
Viszont ez nem tűnik egyszerű megoldásnak, rengeteg bridge kell vagy egy bridge rengeteg interfésszel, biztos bele fogok ütközni valami kernel limitbe - Jöhet még ötlet!
- A hozzászóláshoz be kell jelentkezni