IPV6: /64 gebruiken voor virtueel netwerk

[Hmail]

Ik heb het volgende scenario:
1 server met 1 fysieke netwerkkaart (eth0) en 1 virtuele netwerkkaart (vmbr0) die een serie virtuele machines host. Op dit moment NAT de server 1 extern IPV4 adres naar de virtuele machines. Ik heb van de provider (Leaseweb) een serie global IPV6 adressen gekregen in een /64 netwerk. Deze adressen wil ik graag inzetten op de virtuele machines.

Met IPV4 zou ik deze ip adressen gewoon stuk voor stuk doorsturen naar een intern adres, maar ik kan niet uitvinden hoe (en of) het mogelijk is om ditzelfde te doen met IPV6. Het enige dat ik tegenkom is de mogelijkheid om een /48 netwerk op te delen in /64 netwerken, en alle machines in 1 zo'n /64 netwerk onderbrengen. Dat gaat dus niet, omdat ik alleen wat losse adressen heb gekregen. Ik ben al aan het proberen een /48 netwerk te krijgen, tot nu toe lijkt dat nog niet erg succesvol.

> Our standard policy for servers located in shared racks, such as yours, is
> assigning 65536 contiguous IPv6 addresses which are part of a shared /64.
> Please note that the IPv6 addresses that have been assigned to you it's not a
> /112, it is a part of a /64.

Dus mijn vraag: Is het mogelijk een los IPV6 ip adres te tunnelen naar een unique local adres? Of is het mogelijk om te routeren in hetzelfde netwerk? Dus dat eth0 het eerste adres in de serie oppakt en dat de rest doorgestuurd wordt naar de virtuele netwerkkaart die het weer verdeelt onder de machines?

Voor de duidelijkheid: het blok dat ik gekregen heb ziet er zo uit:
from: 2001:1AF8:4010:A05E:0002::0000
Until: 2001:1AF8:4010:A05E:0002::FFFF

[ Voor 9% gewijzigd door Hmail op 16-05-2015 13:48 ]

[Xudonax]

Dat ziet er niet als een /64, maar als een veel kleiner netwerk (slechts 0xFFFF of 65535 adressen). Als het een echt /64 is zou je 2^64 adressen hebben, oftewel 18446744073709551616 adressen. In dat laatste geval zou je met bijvoorbeeld radvd de adressen via IPv6 router advertisements kunnen uitdelen. Een andere optie (die mogelijk wél werkt met het beperkte aantal adressen dat je nu hebt) is DHCPv6. Hier heb ik zelf echter nauwelijks ervaring mee, en zo mogelijk nog minder kennis...

[Hmail]

Hmm, excuus, dat had ik iets duidelijker kunnen maken. Ik heb de TS aangepast.

[Xudonax]

Wat je wilt moet volgens mij gewoon met DHCPv6 kunnen, als je de IPv6 adressen tenminste niet per machine handmatig in wilt stellen. Hierdoor worden de adressen automatisch verdeeld over de paar duizend VMs die je zo kunt draaien

[Hmail]

Toch lijkt het niet te werken.. <prefix>::1 kan ik pingen, maar <prefix>::2 kan ik niet bereiken (de VM's heb ik dan nog niet ingesteld). Moet ik hiervoor radvd gebruiken? Ik heb nu dus feitelijk twee netwerkkaarten op de machine die wel te bereiken zijn op de machine zelf, maar niet vanaf extern.
Ik heb ingesteld dat forwarding mogelijk is (net.ipv6.conf.all.forwarding = 1), firewall staat uit en ik zie de pakketten binnenkomen (who has <prefix>::2) maar krijg geen response.

Ik ging er vanuit dat dat kwam omdat ik het protocol gewoon niet genoeg begreep, maar kan het ook een Linux issue zijn? Dit is wat er ingesteld is:

code:

iface eth0 inet6 static
        address 2001:1AF8:4010:A05E:0002::0001
        netmask 64
        gateway 2001:1AF8:4010:A05E::1

iface vmbr0 inet6 static
        address 2001:1AF8:4010:A05E:2::0002
        netmask 64
        gateway 2001:1AF8:4010:A05E:2::1

Daarmee krijg ik zo'n routing table

code:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2001:1af8:4010:a05e::/64       ::                         U    256 0     1 eth0
2001:1af8:4010:a05e::/64       ::                         U    256 0     1 vmbr0
fe80::/64                      ::                         U    256 0     0 vmbr0
fe80::/64                      ::                         U    256 0     0 eth0
::/0                           2001:1af8:4010:a05e::1     UG   1024 1     0 eth0
::/0                           ::                         !n   -1  1    28 lo
::1/128                        ::                         Un   0   1     6 lo
2001:1af8:4010:a05e::/128      ::                         Un   0   1     0 lo
2001:1af8:4010:a05e::/128      ::                         Un   0   1     0 lo
2001:1af8:4010:a05e:2::1/128   ::                         Un   0   1    29 lo
2001:1af8:4010:a05e:2::2/128   ::                         Un   0   1     5 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::2a92:4aff:fe2d:65c/128   ::                         Un   0   1    23 lo
fe80::e8c5:aaff:fe31:72cd/128  ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 vmbr0
ff00::/8                       ::                         U    256 0     0 eth0
::/0                           ::                         !n   -1  1    28 lo

Ik heb dus nog geen radvd of dhcp6 geinstalleerd, ik wilde het eerst simpel werkend krijgen en dan extra elementen toevoegen..

[Xudonax]

Zit er een bridge tussen eth0 en vmbr0? Er moet tenslotte iets zijn wat beide interfaces koppelt. Helaas loopt dit flink buiten het stuk waar ik daadwerkelijk kennis van heb, dus ik hoop dat er iemand anders is die je verder kan helpen

[eBait]

Je probleem is dat je een adresrange adverteert die kleiner is dan /64. radvd kan alleen maar /64 ranges addresseren, zoals in de RFC voor stateless autoconfiguration staat. Als je radvd de range 2001:1AF8:4010:A05E::/64 laat adverteren zou dit wel moeten werken. Ik zou persoonlijk je eth0 2001:1AF8:4010:A05E::1 maken, en je vmbr0 2001:1AF8:4010:A05E::2 (als ze beide in hetzelfde subnet zitten, doet de kernel het routeren, dat heb je namelijk aangezet in je sysctl). Succes!

[ Voor 13% gewijzigd door eBait op 16-05-2015 15:08 ]

[johnkeates]

radvd voor /64, DHCPv6 voor de rest

Wat voor firewall gebruik je voor je hypervisor bridge setup? En heb je bij Leaseweb bare metal draaien of een setje cloud instances?

Ik draai vaak bare metal, daar komt dan Xen op met pfSense. Dan OpenVSwtich of brctl voor 2 of meer brdiges, tenminste 1x wan en 1x guests, hypervisor en pfSense op wan, pfSense ook op guests en alle domU's ook op guests om een voorbeeld te geven. Trunken tussen servers is ook makkelijk te regelen, extra vswitch er bij, of vswitches gewoon aan elkaar rijgen zodat je een grote overkoepelende vswitch hebt op alle servers bijv.

[eBait]

Dat zou kunnen, maar hij heeft een /64 gehad. Als je gewoon je eth0 en vmbr0 een adres uit deze range geeft, en daarna radvd die range laat adverteren zal er nooit een conflict optreden, omdat alle andere apparaten vanuit hun (virtuele) mac adres laten addresseren. Lijkt me wel zo makkelijk toch?

[Hmail]

De reeks 2001:1AF8:4010:A05E::/64 kan ik niet zomaar laten adverteren neem ik aan? Ik mag geen ip adressen instellen die niet van mij zijn, dus ik vraag me af of dat de bedoeling is. 2001:1AF8:4010:A05E::1 is bijvoorbeeld de gateway van Leaseweb, dus het lijkt me dat dat problemen gaat geven..

johnkeates schreef op zaterdag 16 mei 2015 @ 15:10:
radvd voor /64, DHCPv6 voor de rest

Wat voor firewall gebruik je voor je hypervisor bridge setup? En heb je bij Leaseweb bare metal draaien of een setje cloud instances?

Ik draai vaak bare metal, daar komt dan Xen op met pfSense. Dan OpenVSwtich of brctl voor 2 of meer brdiges, tenminste 1x wan en 1x guests, hypervisor en pfSense op wan, pfSense ook op guests en alle domU's ook op guests om een voorbeeld te geven. Trunken tussen servers is ook makkelijk te regelen, extra vswitch er bij, of vswitches gewoon aan elkaar rijgen zodat je een grote overkoepelende vswitch hebt op alle servers bijv.

Hmm, dit gaat me toch echt even te diep Ik heb een bare metal server, en ik heb hier Debian op draaien. Vervolgens maakt Proxmox een aantal KVM virtuele machines.
pfSense gebruik ik niet, ik ken eigenlijk alleen iptables als firewall, en die heeft geen regels voor ipv6. OpenVSwitch of brctl gebruik ik niet.. Begrijp ik je goed dat ik een bridge moet leggen tussen deze twee netwerkkaarten? Ik heb dit in een eerder stadium geprobeerd maar kon dan de machine niet gebruiken, en ik ben er vanuit gegaan dat dit kwam door een policy dat 1 netwerkkaart geen 2 mac adressen mocht gebruiken.

Note dat het dus met IPV4 goed gaat, daar kan ik gewoon NAT gebruiken, maar ik begrijp dat dat met IPV6 niet mogelijk is..

[ Voor 3% gewijzigd door Hmail op 16-05-2015 15:25 ]

[eBait]

Hmm. Ik denk eerlijk gezegd dat je radvd wel degelijk kan laten adverteren. De hele range minus het eerste adres is dus van jou. Wat ik zou doen is eth0 ::2 geven, vmbr0 ::3, en daarna radvd laten adverteren met 2001:1AF8:4010:A05E::/64 als netwerk en 2001:1AF8:4010:A05E::1 als gateway. Ik kan niet verzinnen waarom dit niet zou werken

edit, clarification
Het neighbor discovery protocol zou de routes moeten genereren, anders kun je ::2 als default gw instellen.

[ Voor 16% gewijzigd door eBait op 16-05-2015 15:29 ]

[Hmail]

Voor de zekerheid (en voordat mijn server stopgezet wordt ) dit is dus de reeks die ik gekregen heb:
from: 2001:1AF8:4010:A05E:0002::0000
Until: 2001:1AF8:4010:A05E:0002::FFFF
En dit is dan de gateway: 2001:1AF8:4010:A05E::1

Bedoel je dan dat ik de reeks 2001:1AF8:4010:A05E:0002:: kan adverteren of 2001:1AF8:4010:A05E::?

[Xudonax]

Mensen, enkel de laatste 16 bits zijn beschikbaar voor Hmail he
Radvd gaat dus niet werken aangezien er slechts een /112 beschikbaar is, geen vol /64.

EDIT: Inderdaad een /112, want van de 128 bits in het adres zijn er nog 16 beschikbaar. Stom ^_^

[ Voor 25% gewijzigd door Xudonax op 16-05-2015 18:13 ]

[eBait]

Oooh - wacht even. Ik zie het. Wat Xudo al zei, ik dacht inderdaad dat je een volledig /64 tot je beschikking had. Ik zou eens gaan klagen bij Leaseweb want dit is toch wel een redelijke boutoplossing. Succes met DHCPv6, ik moet mijn vlucht gaan halen helaas

[Bigs]

Xudonax schreef op zaterdag 16 mei 2015 @ 15:29:
Mensen, enkel de laatste 16 bits zijn beschikbaar voor Hmail he
Radvd gaat dus niet werken aangezien er slechts een /16 beschikbaar is, geen vol /64.

Een /112, geen /16. Maargoed beter vraagt hij bij z'n provider om een /64 ja.

[johnkeates]

Ik zou voor dat je dingen gaat doen eerst je infrastructuur af maken

Hoeveel IPv4 adressen heb je en heb je IPKVM/DRAC/ILO/IMM?

Stap 1: Gebruik linux bridges om verkeer te scheiden, maak er minimaal twee.
Dit kan permanent door je bridge in /etc/network/interfaces te configureren.
Voorbeeld:

code:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet manual


auto wanbr0
iface wanbr0 inet static
        address a.b.c.d #WAN IP
        netmask a.b.c.d #WAN Subnet
        network a.b.c.d # optioneel: WAN net
        broadcast a.b.c.d #WAN Broadcast
        gateway a.b.c.d #WAN gateway
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 8.8.8.8 #om maar wat te noemen, je kan het beste leaseweb DNS gebruiken
        bridge_ports eth0
        bridge_fd 0
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off
    bridge_hw e8:39:35:aa:aa:aa # in theorie ishet handig de MAC van eth0 hier te gebruiken


auto guests0
iface guests0 inet manual
        pre-up    brctl addbr $IFACE
        up        ifconfig    $IFACE up
    post-up ip link set   guests0 address 00:16:3e:1d:1c:11 #een random MAC, bijv. uit de XenSource range
        down      ifconfig    $IFACE down
        post-down brctl delbr $IFACE

Stap 2: Installeer een pfSense KVM instance met een interface op zowel wan als guests
Stap 3: Configureer pfSense comfortabel vanuit een browser
Stap 4: alle guests kunnen nu via pfSense het internet op via NAT

Optioneel: je kan nu ook 1:1 NAT doen met WAN naar Guest adressen, en je kan IPv6 tracking en firewalling gebruiken zonder NAT.

De wanbr is in dit geval de bridge voor WAN verbindingen en ook de interface in ifconfig voor je hypervisor (KVM/Proxmox/Debian in jouw geval). pfSense is het makkelijkste te configureren na installatie door een SSH tunnel te gebruiken. Klinkt gek, maar echt, het is makkelijk.

Stappen daar voor:

1. SSH een reverse tunnel naar je hypervisor
2. vraag een DHCP adresje van je verse pfSense config (bijv. sudo dhclient guests0)

ga lokaal naar https://localhost:12345 (of whatever je voor je tunnel gebruikt) en je kan bij de web interface.

Voorbeeld:

ssh user@ip-van-proxmox -L12345:192.168.1.1:443

Dan kan je lokaal op je computer op https://localhost:12345 met pfSense aan de andere kant van de tunnel op 192.168.1.1:443 babbelen.

In pfSense heb je robuuste firewalling met een nette interface. Zit ondersteuning voor zowat alles wat je maar kan verzinnen in, incl. diverse VPN opties die weer handig zijn als je je proxmox guests wil benaderen.

[ Voor 21% gewijzigd door johnkeates op 16-05-2015 15:50 ]

[Osiris]

't Is toch te bizar voor woorden dat een professionele tent als Leaseweb slechs een /112 uitdeelt aan z'n klanten?

Ik zou eens flink bij ze gaan klagen dat 't nergens op slaat en dat ze op z'n minst een /64 moeten uitdelen.. Heck, bij ISP's krijg je als niet-zakelijke klant al een /48 (XS4ALL)

[Hmail]

Ha, van XS4ALL heb ik inderdaad ook een /48 gekregen, met een virituele omgeving had ik dit ook vrij eenvoudig werkend. Ik ging er vanuit dat ik het niet werkend kreeg omdat ik het protocol niet genoeg begreep, maar het probleem lijkt dus gewoon bij het minimale aantal adressen te liggen. Ik zal vragen hun beleid te herzien

Ik ben nu met johnkeates' bridge oplossing bezig, wellicht dat ik het dan werkend krijg. De vorige keer kwam mijn server niet meer op toen ik een bridge wilde leggen, dus het zal me benieuwen

[ Voor 23% gewijzigd door Hmail op 16-05-2015 16:00 ]

[johnkeates]

Osiris schreef op zaterdag 16 mei 2015 @ 15:55:
't Is toch te bizar voor woorden dat een professionele tent als Leaseweb slechs een /112 uitdeelt aan z'n klanten?

Ik zou eens flink bij ze gaan klagen dat 't nergens op slaat en dat ze op z'n minst een /64 moeten uitdelen.. Heck, bij ISP's krijg je als niet-zakelijke klant al een /48 (XS4ALL)

Je krijgt gewoon wat je aanvraagt hoor. Stel dat je gewoon a-la-default zegt dat je graag IPv6 wil, dan krijg je hun kleinste unit. Je kan ook specifiek voor een /64 of groter gaan.

Hmail schreef op zaterdag 16 mei 2015 @ 15:58:
Ik ben nu met johnkeates' bridge oplossing bezig, wellicht dat ik het dan werkend krijg. De vorige keer kwam mijn server niet meer op toen ik een bridge wilde leggen, dus het zal me benieuwen

Ik zou je aanraden dit via de ip KVM te doen, en niet via SSH. Je kan wel via SSH de config er even in plempen, maar het activeren/rebooten zou ik toch wel via een remote console doen

In principe heb je als je die config zo overneemt (wel de MAC adressen even opnieuw genereren!), en de IP adressen goed invult, na een reboot een werkende setup. Ik gebruik die om bij non-OpenVSwtich configuraties bij automatische deployments snel een bridge te hebben via SaltStack, dan moet het voor 1 server met de hand ook wel werken

[ Voor 41% gewijzigd door johnkeates op 16-05-2015 16:05 ]

[Hmail]

IP KVM heb ik vorige week al aangevraagd maar daar krijg ik geen response op. En nu komt hij dus weer niet op. Ik ga je reply even bookmarken voor als ik eindelijk KVM toegang heb ga ik met je replies aan de slag. Thanks voor je uitgebreide uitleg!

Ik heb ze trouwens expliciet gevraagd om een /48 netwerk. Ik wil een VPN netwerk erbij gaan bouwen, en ruimte hebben om in de toekomst VPS'en gaan verhuren.

[ Voor 24% gewijzigd door Hmail op 16-05-2015 16:18 ]

[johnkeates]

VPN via pfSense is ideaal. Kan ook met RADUIS, LDAP, AD enz integreren. Kan je VPN-via-LDAP doen, credentials aan een klantpoortaal koppelen enz. OpenVPN, IPSec, L2TP, alles. PPTP zou ik niet inschakelen

Er zit ook goede DNS support in via dnsmasq en unbound, dus ook daar ruime opties. Je kan ook per-VM netwerk isolatie maken, en extra firewall regels per VM en VM netwerk maken. Hell, je kan zelfs gebruikers toestaan in te loggen op de firewall en dan alleen hun eigen firewall regels laten bewerken met ACLs

Is hij trouwens nog steeds niet up? Heb je bridge spul wel geïnstalleerd? En heb je ook geen SoL? Doet ie geen SSH maar wel ping? En heb je IPKVM wel via SSC aangevraagd via een ticket naar Sales? Want dat werkt het beste. Anders moet iemand daar je opdracht uit de normale communicatie backlog zien te vissen en door sturen naar de juiste afdeling wat altijd weer lang duurt

Voor VM's verhuren via Proxmox is pfSense + IPTables + bridges trouwens de beste combinatie:

- pfSense voor je algemene bescherming, transparante filtering en logging enz. (dus zonder NAT en DHCP is mogelijk, maar je kan je VM's dan wel weer via DHCP hun WAN IP geven bijv.)

- IPTables voor end-user firewall opties, dan hoeven ze niet bij pfSense en kan je een leuke interface aanbieden

- Bridges voor per-vm isolatie als ze niet met elkaar mogen babbelen of het idee hebben dat ze op een intern netwerk zitten (je kan ook OpenVSwitch gebruiken en dan port isolation gebruiken of zelfs VLANs)

Je kan eigenlijk dan het beste een goede marge op je KVM (dus de hypervisor) host houden, want KVM gaat over z'n nek bij hoge IO, dus dat is iets om rekening mee te houden. Xen heeft daar geen last van, maar is misschien een stap te ver zo

[ Voor 31% gewijzigd door johnkeates op 16-05-2015 16:47 ]

[Hmail]

Nee, ik ben aan het wachten op de rescue mode, dat duurde vorige keren ook een eeuwigheid. Die technieken ga ik zeker eens mee spelen als ik KVM toegang heb en een reactie op de IPV6 addressering. Ik heb KVM nu via een ticket aangevraagd, de vorige keer via het support adres.

[johnkeates]

Hmail schreef op zaterdag 16 mei 2015 @ 16:59:
Nee, ik ben aan het wachten op de rescue mode, dat duurde vorige keren ook een eeuwigheid. Die technieken ga ik zeker eens mee spelen als ik KVM toegang heb en een reactie op de IPV6 addressering. Ik heb KVM nu via een ticket aangevraagd, de vorige keer via het support adres.

Ah ja, rescue mode. Dat is een leuk proces duurt inderdaad lang;

- je komt in een queue
- je server komt in de pxe boot pool
- je server krijgt een APC reboot op z'n donder
- je server gaat tergend traag opstarten en pxe boot doen over het netwerk

Het is fijn dat het er is, maar leuk is anders idd. Soms duurt het een half uur voordat Frenzy of wat je ook kiest geladen is. Is ook niet altijd even betrouwbaar als je je BIOS settings bijv. aangepast hebt dan hangt PXE gewoon en is alles stuk. Maar dat is in jouw geval ongetwijfeld niet zo.

[CyBeR]

Osiris schreef op zaterdag 16 mei 2015 @ 15:55:
't Is toch te bizar voor woorden dat een professionele tent als Leaseweb slechs een /112 uitdeelt aan z'n klanten?

Dit gaat om shared colo. Daarbij zit je zowel bij IPv4 als bij IPv6 in een subnet wat je deelt met de andere klanten in hetzelfde rack. Leaseweb deelt dus geen /112 uit maar gewoon 65000 adressen voor een server in een gedeeld subnet. Als jij een heel rack afneemt krijg je wel een /48.

In ieder geval: TS moet gewoon z'n eth0 bridgen naar de VM's toe en dan individueel een IP-adres toewijzen uit de range.

Dit is vergelijkbaar met in IPv4 in een /24 zitten en dan 1.2.3.1 tot en met 1.2.3.6 mogen gebruiken.

[ Voor 7% gewijzigd door CyBeR op 16-05-2015 17:19 ]