Testomgeving met native IPv6

[EWS99]

Ik heb een webshop waarbij ik een aantal keer gezien heb dat betalingen niet door komen. Ik denk dat terug te kunnen herleiden naar bestellingen door klanten die via IPv6 op mijn site komen. Nu wil ik dit graag zelf kunnen reproduceren, maar heb helaas geen internet verbinding met IPv6 tot mijn beschikking.

Nu weet ik dat het mogelijk is om een tunnel op te zetten om toch IPv6 te kunnen gebruiken, maar voordat ik een kerstboom op ga tuigen voor een uurtje test werk dacht ik: dat moet makkelijker kunnen. Ik dacht aan een VPS met native IPv6, waarbij ik ook nog eens IPv4 uit kan schakelen zonder gevolgen.

Gister vol enthousiasme begonnen met Azure. Want wat is er mooier dan een testomgeving op een public cloud waarbij je per uur af kunt rekenen? Bleek dat IPv6 nog niet zo voor de hand liggend was (moest een loadbalancer optuigen etc.). Helaas was ik mijn VM kwijt nadat ik IPv4 uitschakelde. Daardoor helaas niet bruikbaar voor mijn testjes. Ik heb ook AWS bekeken, maar kan er niet goed uit halen hoe zij IPv6 hebben geregeld.

Ik heb nodig:
- Een VM (liefst een Windows OS, maar dat is geen vereiste) voor ongeveer 2 uurtjes
- Performance etc. is natuurlijk onbelangrijk
- Native IPv6
- Mogelijkheid tot uitschakelen van IPv4

Iemand nog een goed idee? Ervaringen met een andere public cloud of VPS met IPv6?

[Trommelrem]

Ken je niemand met een XS4ALL of RoutIT verbinding? Beiden bieden native IPv6.

[MAX3400]

digitalocean
vultr

Beiden goedkope VPS en zelfs soms afrekenen per seconde.

TransIP en OVH zijn duurder maar wel technische support.

Je stelling klinkt vreemd; als een IPv6 klant wel op jouw site kan komen, is er al een IPv4 translatie gedaan waarschijnlijk op een tussenliggende hop. Sterker nog, jouw webshop heeft zowel IPv6 als IPv4 records.

Ik twijfel dus heeeel erg aan de voorlopige constatering; kan je de klagende klanten niet aanschrijven dat ze korting krijgen op produkt X als ze willen meewerken aan (geavanceerdere) logging voor hun sessie?

Waar draaait de betaling trouwens? Jij bent geen bank dus ik ben bang dat het issue tussen payprovider en jouw klant zit; niet op IP-niveau.

[Brahiewahiewa]

Met ^^

Anyway, een ipv6 tunnel via he.net is sneller opgezet dan een topic op tweakers.net ;o)

[CyBeR]

Inderdaad. Overigens heeft Amazon AWS wel gewoon native IPv6 op hun EC2 vms. Geen truukerijen met load balancers.

[Kees]

MAX3400 schreef op donderdag 31 augustus 2017 @ 21:59:

Je stelling klinkt vreemd; als een IPv6 klant wel op jouw site kan komen, is er al een IPv4 translatie gedaan waarschijnlijk op een tussenliggende hop. Sterker nog, jouw webshop heeft zowel IPv6 als IPv4 records.

Waar draaait de betaling trouwens? Jij bent geen bank dus ik ben bang dat het issue tussen payprovider en jouw klant zit; niet op IP-niveau.

En dat probleem kan prima op ip-nivo zitten. Bijvoorbeeld een slecht werkende ipv6 bij de paymentprovider.

Overigens zou ik dat issue wel testen met zowel een tunnel als met 'native' omdat daar ook verschillen inzitten en problemen soms bij een tunnel wel optreden maar niet bij een native verbinding.

[webgangster]

Ik kan je wellicht helpen met een VM dat een IPv6 verbinding heeft.
Laat maar weten.

[EWS99]

Ik had 2 weken geleden op Campzone een native IPv6 en IPv4. Ik heb toen wat testen gedaan, maar kon het probleem niet reproduceren. Had het toen op een eenmalige incident gehouden. Heb deze week echter weer hetzelfde probleem gezien, vandaar dat ik graag met alleen IPv6 wil testen en IPv4 uit wil schakelen.

Een Sixxs tunnel opzetten is inderdaad niet veel werk, maar omdat het dan om een IPv6 tunnel over IPv4 gaat, kan ik IPv4 niet uitschakelen. Tuurlijk kan ik op mijn thuis router die tunnel opbouwen, maar met een huis vol domotica (en dan bedoel ik ook echt vol), iot apparaten, en een vrouw die productie draait met meerdere webshops is er niet echt veel ruimte om te experimenteren. Moet er niet aan denken dat mijn apparaten rechtstreeks aan internet hangen, zonder dat ik eerst goed heb kunnen testen met een firewall. Ik houd de Sixxs tunnel nog wel even open als optie, maar dacht dat het wel makkelijker zou zijn met een tijdelijke VM op een public cloud. Ik geef Kees gelijk dat tunnels weer andere issues hebben dan native IPv6.

Het probleem zit zeker tussen de klant en de betaling provider. Ik heb daar uiteraard een support ticket lopen. De kans is echter groot dat ze meer informatie nodig hebben en ik wil graag zelf het probleem kunnen reproduceren.

Als AWS native IPv6 ondersteund, ga ik daar zeker mee testen! Als het niet lukt dan kan wellicht iemand hier, met een XS4All verbinding, of met een public VM, mij wel verder helpen denk ik.

[Brahiewahiewa]

EWS99 schreef op vrijdag 1 september 2017 @ 10:50:
... omdat het dan om een IPv6 tunnel over IPv4 gaat, kan ik IPv4 niet uitschakelen. Tuurlijk kan ik op mijn thuis router die tunnel opbouwen, maar met een huis vol domotica (en dan bedoel ik ook echt vol), iot apparaten, en een vrouw die productie draait met meerdere webshops is er niet echt veel ruimte om te experimenteren. Moet er niet aan denken dat mijn apparaten rechtstreeks aan internet hangen...

Je overdrijft. De sixxs of he tunnel termineert op een - al dan niet virtuele - machine. Die machine heeft zowel ip4 als ip6. Een - al dan niet virtuele - client heeft dan voldoende aan een ip6 adres en is dan op ip-niveau, volledig geïsoleerd van de rest van je netwerk

[Vorkie]

Als je trouwens een server op IPv6 only gaat zetten, hoe wil je deze dan benaderen vanuit een IPv4 omgeving?

Even een gedachte, theoretisch zal dit moeten werken

Vraag een he.net IPv6 tunnel aan
Installeer een Linux distro
Haal de default gateway weg van Ipv4.
Maak een static route aan van het Ipv4 adres van de tunnel naar het Ipv4 gateway adres (zo kan de tunnel opgebouwd worden.
Bouw de tunnel op, daarin zit dan gelijk de Default IPv6 gateway (de enige gateway op de computer)

Zo kan de client alleen in zijn eigen interne reeks op Ipv4 connecten (dus jij ook met VNC) en op Ipv6 alleen naar de buitenwereld (het internet)

Als je geen RAdeamons gebruikt en dus ook je Ipv6 prefix niet rondbazuint op je netwerk, krijgen de andere clients geen IPv6 adres. (dwz geen router broadcasts)

[ Voor 0% gewijzigd door Vorkie op 01-09-2017 21:30 . Reden: RDP op linux wat een lachertje... ]

[webgangster]

Vorkie schreef op vrijdag 1 september 2017 @ 21:28:
Als je trouwens een server op IPv6 only gaat zetten, hoe wil je deze dan benaderen vanuit een IPv4 omgeving?

Even een gedachte, theoretisch zal dit moeten werken

Vraag een he.net IPv6 tunnel aan
Installeer een Linux distro
Haal de default gateway weg van Ipv4.
Maak een static route aan van het Ipv4 adres van de tunnel naar het Ipv4 gateway adres (zo kan de tunnel opgebouwd worden.
Bouw de tunnel op, daarin zit dan gelijk de Default IPv6 gateway (de enige gateway op de computer)

Zo kan de client alleen in zijn eigen interne reeks op Ipv4 connecten (dus jij ook met VNC) en op Ipv6 alleen naar de buitenwereld (het internet)

Als je geen RAdeamons gebruikt en dus ook je Ipv6 prefix niet rondbazuint op je netwerk, krijgen de andere clients geen IPv6 adres. (dwz geen router broadcasts)

Gewoon de 'console' openen?

[EWS99]

Gister nog wat zitten stoeien met een AWS VM, maar kreeg het netwerk/internet gateway niet aan de praat, waardoor ik geen verbinding kon maken met die VM. Ik ga er binnenkort nog wel wat meer mee prullen, zonder meer leuk speelgoed om in te testen.

Inmiddels is de oorzaak van het initiele probleem gevonden. De webshop (Magento2) sloeg het IP adres op in een VARCHAR(32). Dat kan bij sommige korte IPv6 adressen voldoende zijn, maar als een IPv6 helemaal uitgeschreven is, dan gaat dat niet passen. Heb inmiddels de VARCHAR aangepast naar 48 in de database waardoor dit probleem verholpen moet zijn.

Verklaard in ieder geval wel waarom ik het probleem op Campzone niet heb kunnen reproduceren. De IPv6 adressen waren daar een stuk ingekort en paste dus in die 32 karakters.