Sziasztok,
van egy tunnelezett ipv4-es hálózat, amelyet fel szeretnék vértezni ipv6 -al is. A végponton van ipv6 (és sajnos router advertisement is); illetve a vpn másik felén a belső hálózaton úgyszint elérhető az ipv6 (dnsmasq szórja ra -val).
Valamilyen full nat megoldást szeretnék (a végponton statikus címeket használok, ezek közül az egyiket szeretném átvezetni tinc -en keresztül).
De:
ha van ra a végponton, akkor nincs forward
ha nincs ra a végponton, akkor nincs gateway, viszont van forward
mivel a tinc natívan /64 vagy /56 vagy /48 -at kezel, így nincs arra jelenleg leheőségem, hogy a jelenlegi /64 -et tovább bontsam.
Ti milyen megoldást alkalmaznátok? Egyáltalán keresztülvihető -e ez így?
VPN GW:
eth0 > publikus 2001:4c48:0:xxxx::100/64 - Ez a cím lenne "natolva"
tap1 > tinc végpont fd10::1/64 címmel
-----
Irodai hálózat:
tap1 > tinc végpont a belső hálózaton fd10::2/64 címmel
eth0 > fd00::1/64 ez a dnsmasq altal szort halozat
Ha nincs forward belőve a tinc végpont és a publikus cím közt, akkor a 2001:4c48:0:xxxx::100 elérhető; bekapcsolt forwardnal az ipv6 ezen az interface -on meg is szűnik azonnal.
Tudom, hogy az ipv6 nat folosleges, vanelegcim, stb., viszont konnyebben menedzselhetőnek tartanék egy ilyen megoldást, mintha még a nyomorék nyomtató is azonnal megjelenne a fél világ előtt, mert a user eszközökön nehezen tudok restriktálni az eltérő szoftverkörnyezetek miatt is.
Előre is köszi :)
Hozzászólások
Ha a tunneled tap, akkor miért nem bridge-eled simán össze az ethernet interfésszel és a két telephely egyetlen LAN-ként viselkedik, amiáltal az IPv4 és a minimálisan ajánlott /64-es IPv6 tartomány is gond nélkül üzemel.
Lásd: https://openvpn.net/index.php/open-source/documentation/miscellaneous/7…
Itt a problema nem magaval a tunnellel van, hanem azzal, hogy mindenkepp szeretnek NATolt megoldast, ami a forward hianya miatt meghiusulni latszik. Tehat, ha nincs forward, egeszen a publikus ipv6 cimig el tudok tracerouteolni, a forward bekapcsolasaval (mivel accept_ra!=0) azonnal eltunik a publikus interface, kompletten. Az accept_ra=2 elvileg megoldana a publikus if -en, de nem teszi...
fel! iratkozom
+1
Tudsz esetleg egy ábrát gyártani? Mi a célja az IPv6-nak ebben az esetben? Mit akarsz vele megoldani?
Az ipv6 általános bevezetésével együtt portfolion belül szükségessé vált a kliens gépek ipv6 elérését is biztosítani.
Hevenyészve kb így fest az ipv4:
Belső hálózat (192.168.1.0/24) -> int. gateway -> VPN (192.168.3.0/24) -> pub. gateway (x.x.x.x/23) + portfolio belso halozat (10.0.0.0/8)
Jelenleg ipv4 -en full NAT van a pub. gateway irányából az int. gateway irányába; bejövőben értelemszerűen csak established, related van. A pub gateway erre dedikált ip -re snat -olja a kimenő forgalmat publikus irányban; belső hálózaton szimplán maszkolva van. A forgalomszabályzás (tc), és a router funkcionalitás, csomagszűrés, source based routing mind az int. gateway -en van megvalósítva. A VPN létjogosultsága a szokásos okok mellett a bondingra (failover) ültetett tunnelben rejtezik (nem szerencsés, ha egy munkamenetben váltogatjuk a source addresseket).
Ugyanezt a megvalósítást szeretném elérni ipv6 -on is; ez jelenleg csak és kizárólag publikus hálózatot jelent.
Upd: a problema ezzel a topikinditoban es itt: https://hup.hu/node/153549#comment-2100662
Elökjáróban: a NAT-tal az a probléma,hogy ha még technikailag működene is, a kliens operációs rendszerek source address selecton-je nem fogja szeretni a site local címeket, és ezért nem fogja használni sem azokat. Ezért is kérdeztem, hogy mi a cél a NAT-olással, mert 100-ból 99 esetben nem használható IPv6 mellett.
Én ND proxy-val próbálkoznék, de sajnos még mindig nem látom át annyira a hálózatodat, hogy konkrét javaslatot tegyek. Igyekszem gondolkozni rajta.
Ezt az állítást nem erősíteném meg. Több telephely, mindenhol site-local IPv6 cím a klienseken. Természetesen a gw itt is egy site-local IPv6 címmel is rendelkező masina. Telephelyen belül simán megy az IPv6 site-local címekkel, nincs gond azzal, hogy mi is legyen a source IP. (Mondjuk telephelyek között viszont nincs NAT - de ez a klienst, amelyik nem tud róla, nincs is köze hozzá, hogy van-e NAT, nem kéne hogy befolyásoljon bármit is.) Nem kevered a site-local címet a link-local-lal? Mert az valóban nem route-olható...
Ja igen: telephelyenként eltéső site-local IPv6 osztva...
A kulcs az, hogy telephelyen belül. Az internet felé (=publikus IPv6 címek elérése) nem fog működni.
Ezért próbálom kifaggatni a kollégát, hogy mire akarja az IPv6-ot használni, mert sokszor IPv4-gyel analóg módon próbálnak problémát megoldani, ami nem fog sikerülni.
Egyértelműen Nálunk is a Kollega által említett eset áll fenn. A nem fog működni vs. működni fog dolog ez esetben privát hálózatomon már megdőlt, hiszen (pont az általam használt tinc -el) a saját vps -emen keresztül nagyon szépen érek el ipv6 szolgáltatásokat.
Három differencia van mindössze:
-a default gateway a saját hálózatomban az én szolgáltatómnál statikusan van megadva (erre jelenleg, plusz info hijjan -van slaac, meg ipv6, örüjjé, vagyvegyélmégplusztartományt- nincs lehetőségem )
-a tinc egyik, illetve másik vége a gateway és a saját gépem
-az en szolgaltatom nem router advertisementet hasznal (es szerintem itt a probléma, ahogy már a topicindítóban is pedzegettem)
Én úgy vettem észre, hogy a masquerade/snat minden további nélkül megy ipv6 -on
Időközben utánaguglizva sem találtam használható megoldást. Illetve annyit, hogy csinalok egy masik vegpontot, a sajat peldambol kiindulva, a sajat szolgaltatomnal, amit pont nem akartam, mert szeretem az SPOF -et, igy hacsk lehet, minden egy helyen koncentralodjon :D.
Még mindig nem látom, még azt sem hogy hány darab eszközöd van. Tudnál egy ábrát rajzolni?
Pl.
-az en szolgaltatom nem router advertisementet hasznal (es szerintem itt a probléma, ahogy már a topicindítóban is pedzegettem)
vs.
A végponton van ipv6 (és sajnos router advertisement is);
Biztos jókat írsz, de egyszerűen átláthatlan külső szemlélő számára, hogy mi a végpont, gateway stb.
ha jól értelmezem a kollega leírását, valahogy így nézhet ki:
https://drive.google.com/file/d/0BxBsJPQIy-5MUU5fSjI2bERRd1E/view
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
Ohhohohohhhh Hat honnet ismered a topologiat? h4x0r! ;)
Pardon, valóban pontatlan voltam.
A site-local IPv6 cím ugyan route-olható, de pontosan úgy, mint az IPv4 privát tartományok: csak saját hálón belül. Tehát az nem probléma, hogy a telephelyek között működjön - a netre való mászkálás már egy másik történet. Viszont. Mivel elhangzott a NAT is, az IPv6 esetén sem jelent problémát, hogy a határon lévő tűzfal a site-local IPv6 forrással rendelkező csomagot a net felé már valamiféle valós IPv6 címmel adja fel. Még az sem feltétlenül szükséges, hogy a saját IPv6 címét használja, simán tolhat olyat is, ami hozzá esik be a neki adott /64-be. Ezzel sokkal könnyebb 1:1 NAT-ot csinálni - bár ez utóbbi felvet olyan kérdést is, hogy ekkor igazából a másik irányból is direktben elérhetővé válhat a belső gép - persze ennek azért még van pár feltétele, de az eredeti kérdésben ez nem szerepelt.
ki képes így megbonyolítani egy hálózatot?
sub :)
Egyszerubb az, mint amire gondolsz ;)
Nekem van egy szerverem, amihez van /56 tartomány. Abból fogtam és hazavittem /64-et 6to4 tunellel amit belül ugye RA val osztok tovább. Mondjuk ettől függetlenül megvannak a belső v6 címek is, de eszembe se jutott NAT-olni.
Inkább a routeren beállítottam, hogy bejövő forgalom nincsen és kész. Innentől kezdve nem nagyon hat meg, ha a nyomtatónak is van v6 címe.
Fedora 25, Thinkpad x220
Bejovo nincs? icmpv6 nelkul azert csunyan meghalunk :) (es ezt ugye forwardolni is kell)
Vegul workaround lett a megoldas:
kliens gepek dnsmasq -val slaac es dhcpv6 segitsegeel kapnak fd00::/64 ULA -bol cimet, amely forwardol az fd10::1/64 -re, mint gw -re, amely egy masik szolgaltatonal vegzodik, akinel van statikus /64, sit tunnelen (amely ipv4 -es vpn -re ül) keresztül.innet mar csak egy ujabb forward (+ full NAT egy erre dedikalt ipv6 cimről/re) van a publikus iranyba (tehat vegso soron NAT66 lett a dologbol (bad idea, stb :)) ).
Remekül működik, mikoözben az irodai gateway -en kényelmesen tudom menedzselni a forgalmat. Az egyetlen, amit a Kollegak eszrevettek, az talan egy 1 sec -es kieses volt, amig a dnsmasq ujraindult :)
Köszönöm az ötleteket mindannyiotoknak :)