Fórumok
Sziasztok!
Némileg küzdök az IPv6-tal. Az a helyzet, hogy az IPv4-es címekkel spórolnom kellene és ezen felül egy közös domain név alatt szeretnék különböző szolgáltatásokat üzemeltetni (http, git, jabber, stb). Azt viszont nem szeretném, hogy ezek mind egy gépben lakjanak, úgyhogy szét kellene választani valahogy. IPv4-en a DNAT tökéletes megoldás, viszont IPv6-on ugye nincs. Az sem túl szimpatikus, hogy TCP proxyt vezessek be, mert akkor a remote cím nem kerül be az auth logba.
Bonyolításként még van egy proxy_ndp is a játékban.
Mit javasoltok a probléma megoldására?
Köszönöm
János
Hozzászólások
Nem látom teljesen világosan mit is szeretnél. Van egy LAN-od ahol üzemeltetni szeretnéd a szerverszolgáltatásokat vagy a szerverek a net-ről elérhetőek, esetleg mindkettő? Van global IPv6 címtartományod vagy site local címeket használnál?
c
Van egy OpenVZ-t futtató gazdagépem és abban szeretném az egyes alkalmazásokat külön virtgépben futtatni, viszont ugyanazon domain név alatt. v6 cím szerint van egy egész /64-em, v4 szerint viszont csak egy /28, szóval az utóbbival takarékosabban kellene bánni. Kívánalom lenne, hogy a fődomain alatt fusson az összes szolgáltatás, ha lehet.
Akkor van IPv6 címed elegendő. :) A megfelelő AAAA rekordok felvétele után hol van a gond? Kiosztod a jabber.domain címet, stb. és felhúzod a megfelelő vírtuális gépet.
c
Az a probléma, hogy jelenleg a domain.tld alatt van a Jabber szerver és így a kliensek automatikusan megtalálják, hova kell csatlakozni. Sajnos van néhány buta kliens, amelyik az SRV rekordokat nem képes figyelembe venni.
Covek jol mondta, aldomaint csinalj! Srv rekord nem fog mindenutt mukodni.
Szerk:
Hasznalhatsz ipv6 to ipv4 gatewayt is es utana mar ipv4-et tudod dnatolni. De ez szornyu megoldas..
Szomorú vagyok.
Ehhehe. Van egy ötletem :))))
IP címnek egy virtuális címet veszel fel (egyik gépnek sem ez lesz a "rendes" címe), kintről rároutolod a virtuális címet a hostra, a host markokat rak a forgalomra iptables-ből (itt ugye akár connection szinten lehet játszani), a markok alapján policy-based routinggal a csomagokat a megfelelő másik gépre/virtuális interfészre routolod, ahol a másik gép/virtulis gép saját IP-ként végződteti a forgalmat (vagy TPROXY-val interceptálva, ha nem akarjuk ugyanazt az IP-t mindenhova felvenni). Ha a hoston is szeretnél valamit végződtetni, akkor rá nem tudod felhúzni ezt a virtuális címet, mert akkor nem tudnál továbbroutolni, így a hoston csak a TPROXY-s megoldás játszik.
Pont ez ötlött föl bennem is, megnézem közelebbről.
Hát még jó, hogy ez egyszerűbb megoldás mint az LVS ... :D
----
올드보이
http://molnaristvan.eu/
Miért, az megy v6-tal?
| CONFIG_IP_VS_IPV6: |
| |
| Add IPv6 support to IPVS. This is incomplete and might be dangerous. |
Láttam már működni.
subs
bevallom oszinten, nem teljesen vilagos a problema a megfogalmazas utan, pedig elolvastam 2x :)
esetleg NAT64?
Létezik egy example.com domain, ami alatt különböző szolgáltatások, különböző portokon futnak. De ezek a szolgáltatások nem csak különböző portokon, de különböző szervereken is futnak.
Itt volt róla szó.
akkor amit linkeltem, helyben van. :)
bent v6os gepek, kulso v4es cimekkel szeretnenek beszelgetni; effektive NATolunk nekik; bar a sima port-forward is mukodhet cimatirassal.
Nem. Ti alapvetően DNAT-ot _ÉS_ SNAT-ot csináltok egyben.
A kérdés az, hogy csak DNAT-ot hogy lehet csinálni (azaz: szeretnénk látni a szerverben az eredeti kliens címét). Az IPv6->IPv4 konverzióval ez is elveszik.
Ez a megoldás ráadásul semmivel nem jobb, mint egy xinetd-s connection forwarding, ott legalább az xinetd-nél meglennének a kliens címek.
ha v4 a kliens, es v6 a szerver, akkor nehez latni az eredeti kliens cimet. amit linkeltem, NAT64, erre reszben megoldas, ugyanis ott be van mappelve ez a cimtartomanyba.
Mikor kerül be a NetBSD-be az npf ipv6 támogatás? Tudni fog NAT64-et?
jovohet vegi commit a cel, meg par dolgot ki kell pucolni a kodhoz, mielott betolom. addig is tesztelheto a githubos kodbol :-)
egyelore nem tud NAT64et, de rajta van a TODO listan.
bevallom oszinten, nem teljesen vilagos a problema a megfogalmazas utan, pedig elolvastam 2x :)
Akkor röviden: amit most DNAT-tal old meg az ember IPv4-en, azt hogy csinálja meg IPv6-on.
ugyanugy? :-)
persze az IETF majd kiabal, hogy v6on ne natolj, meg hasonlok. :)
Az a baj, hogy nem az IETF kiabál, hanem Kadlecsik Józsiék nem implementálták az egész NAT funkcionalitást IPv6-on. Így DNAT sincs :)
olyat tud mar a linux, hogy forrascim alapjan routeolok v6ot? v4re mar jo reg ota, de vajon v6ra? :)
Tudja, ha a kernel az IPV6_MULTIPLE_TABLES és IPV6_SUBTREES opciókkal lett fordítva.
\o/
:))) Látod látod, nem szabad csak úgy írkálni. :)
en csak komolyan kerdeztem, hogy tudja-e! :) mikor ugy 2004ben elkezdtunk v6ozni, nekem ez komoly gond volt. ellenben elismerem keszseggel, hogy NetBSD-ugyileg is lenne mit javitani a dolgon. :)
Több lehetőséget látok:
1. Több IPv6 címet használsz minden szolgáltatásra külön IPv6 cím - IPv6 címmel nem kell annyira spórolni. Majd virtuális gépeket használsz.
2. Átállsz *BSD platformra. Ott van IPv6 redirect a *BSD pf-ben.