[VPS] Opzetten en onderhouden

[Mr-D.]

Heb net ook een testje gedaan,

Ziet er goed uit en zoals ik al eerder typte hij voelt ook lekker snel aan.
Maar de download snelheden haal ik zelf niet.
Heb er zo'n speedtest (librespeed) opgezet maar die geeft toch hele andere waardes

code:

-------------------------------------------------
 nench.sh v2019.07.20 -- https://git.io/nench.sh
 benchmark timestamp:    2025-03-02 11:16:35 UTC
-------------------------------------------------

Processor:    AMD EPYC 9634 84-Core Processor
CPU cores:    8
Frequency:    2246.624 MHz
RAM:          15Gi
Swap:         -
Kernel:       Linux 5.14.0-427.42.1.el9_4.x86_64 x86_64

Disks:
vda    512G  HDD

CPU: SHA256-hashing 500 MB
    0.420 seconds
CPU: bzip2-compressing 500 MB
    3.723 seconds
CPU: AES-encrypting 500 MB
    0.937 seconds

ioping: seek rate
    min/avg/max/mdev = 41.5 us / 134.7 us / 812.8 us / 32.9 us
ioping: sequential read speed
    generated 7.46 k requests in 5.00 s, 1.82 GiB, 1.49 k iops, 372.8 MiB/s

dd: sequential write speed
    1st run:    633.24 MiB/s
    2nd run:    656.13 MiB/s
    3rd run:    649.45 MiB/s
    average:    646.27 MiB/s

IPv4 speedtests
    your IPv4:    89.58.40.xxxx

    Cachefly CDN:         259.74 MiB/s
    Leaseweb (NL):        0.47 MiB/s
    Softlayer DAL (US):   0.00 MiB/s
    Online.net (FR):      142.55 MiB/s
    OVH BHS (CA):         25.28 MiB/s

IPv6 speedtests
    your IPv6:    2a03:4000:66:xxxx

    Leaseweb (NL):        0.31 MiB/s
    Softlayer DAL (US):   0.00 MiB/s
    Online.net (FR):      145.16 MiB/s
    OVH BHS (CA):         26.57 MiB/s
-------------------------------------------------

Ik heb zelf 1GB up and down.

[RobertMe]

RobertMe schreef op zondag 23 februari 2025 @ 20:50:
Na een dagje prutsen begin ik te neigen naar een cancellation binnen 14 dagen bedenktijd

Korte update:
Dinsdag contact opgenomen met "snel snel" het eindresultaat van iperf3 (vanaf thuis + Contabo) er in en daarnaast het laatste regeltje van een ping (dus de min/avg/max).

Dagje later reactie om de resultaten op basis van https://helpcenter.netcup.com/en/wiki/server/rescue-system/ te verzamelen en als bijlage te sturen (ja, slechte pagina, maar ergens staat iets van netwerk problemen incl. gebruik mtr + iperf3). Dat dus woensdag weer aangeleverd. Waarbij ik zelf al wees op de voor mij verbazingwekkende "conclusie" dat de traceroute wijst op dat mijn internetverkeer van Ziggo uit Zuid-Limburg eerst naar een AS van Vodafone in Amsterdam gaat, vervolgens direct naar een AS van Liberty Global in Wenen?! En dan via 3 hops in Duitsland (meen ook van Liberty) terug aankomt in Amsterdam. Aardige WTF dus, dat mijn internetverkeer vaak/altijd via Amsterdam loopt zal best. Maar naar een DC in Amsterdam zou naar mijn idee toch niet via Wenen hoeven.

Vervolgens donderdag reactie dat ze de VPS naar een andere server hadden verplaatst. Maar diezelfde dag (/avond) maar weer terug gemaild dat dat geen verschil maakte.

Maandagavond een mail met de vraag voor toestemming om de VPS in rescue mode te starten en in te loggen. Daarop weer meteen akkoord gegeven.

En gisteravond weer bericht dat ze "iets" hadden aangepast en om opnieuw te proberen. Snelheid vanaf mijn Ziggo lijntje leek daarbij wel iets beter (100-125Mbit/s op een 200Mbit/s down abo), maar vanaf Contabo nog steeds geen 100Mbit/s haalbaar. Maar..., mtr wees wel uit dat het verkeer vanaf Vodafone Amsterdam nu nog maar naar Liberty in Frankfurt gaat, en niet meer naar Wenen. Gevolg was, op een mtr test, een ping van 37ms i.p.v. 50ms. Dus dat was in eder geval iets beter. En deze kortere route leidde wellicht ook tot een iets hogere snelheid? Doordat het mogelijk niet meer over een (over)volle link naar Wenen gaat.
Vervolgens ook maar even een iperf3 server opgezet op mijn router + Contabo VPS (uiteraard achter firewall / IP whitelist), zodat ze zelf kunnen testen vanuit het rescue systeem. En toen kwam ik er ineens achter dat één richting wel de 200Mbit/s naar Contabo haalde. Netcup VPS die download vanaf Contabo lijkt dus prima te zijn, maar Netcup die upload naar Contabo niet. Of dat "intussen" is of altijd al zo was weet ik echter niet. Waarschijnlijker is dat ik gewoon iperf3 met -R heb gedraaid "lokaal", daaruit de 200Mbit/s kwam naar een publieke server, en 30Mbit/s zonder, en ik daarna verder ben gegaan met testen met "-R" gebruik omdat dat "de meest voorkomende richting" is.

V.w.b. support dus 50/50. Ja, intussen wordt er "echt" naar gekeken neem ik aan (gezien de nieuwe route). Maar dat er steeds een dag over nieuw antwoord heen gaat is wel "shitty".
Of ik dan deze week nog ga cancellen weet ik niet. Als ze er echt naar kijken wil ik best verder helpen en "blijven". Maar momenteel as is ga ik de VPS niet gebruiken, en heb ik deze dus ook niet geïnstalleerd, en zou een "hier heb je geld terug totdat het werkt" IMO wel netjes zijn. Nog even kijken dus hoe ik dat ga aanvliegen.

[RobertMe]

RobertMe schreef op woensdag 5 maart 2025 @ 11:59:
V.w.b. support dus 50/50. Ja, intussen wordt er "echt" naar gekeken neem ik aan (gezien de nieuwe route). Maar dat er steeds een dag over nieuw antwoord heen gaat is wel "shitty".
Of ik dan deze week nog ga cancellen weet ik niet. Als ze er echt naar kijken wil ik best verder helpen en "blijven". Maar momenteel as is ga ik de VPS niet gebruiken, en heb ik deze dus ook niet geïnstalleerd, en zou een "hier heb je geld terug totdat het werkt" IMO wel netjes zijn. Nog even kijken dus hoe ik dat ga aanvliegen.

Intussen weer een goede twee weken verder. Contact is "dood gebloed" met van hun kant als laatste een "het is doorgezet naar de netwerk afdeling". Dat ik iperf heb opgezet (thuis en op Contabo VPS) is dus verder geen reactie meer op gekomen behalve dan dat het was doorgezet. Vervolgens heb ik wel nog 1 of 2 mails gestuurd, o.a. dat mijn thuis IP (gek genoeg) veranderd was (gebeurt echt "nooit", maar blijkbaar nu wel) en dus het nieuwe IP doorgegeven, en had modem reboot gedaan waardoor ook de Ziggo snelheidsupdate was doorgevoerd van 200 down naar 250 dus dat ook maar er bij gezet. Dat het intussen 400/40 is heb ik hun nog niet eens over geïnformeerd, ik zat toch nog steeds op hun te wachten. En gek genoeg, lijk ik met die 400/40 wel een iperf3 te kunnen doen waar een snelheid van 200+ uit komt, maar ook daar niet het maximum (IIRC 300-350). Terwijl een run van thuis naar een publieke server prima 390 of meer doet. Het lijkt dus eerder alsof het verkeer gek gesegmenteerd wordt, waardoor er veel meer protocol overhead is of zo (bedenk ik me nu ik dit type).
En de gewijzigde traceroute die ik op een gegeven moment zag..., die zie ik niet meer. Verkeer gaat weer continu via Wenen.

Afgelopen week de VPS wel maar weer opnieuw opgezet, voor ZFS on root met Debian. Dit keer wel gelukt. In de handmatige stappen zit (altijd) een quirk waardoor de zpool export faalt (heb ik op alle systemen gehad waarop ik dit doorlopen heb). Gevolg daarvan "zou moeten zijn" dat de import tijdens boot mislukt (laatst geïmporteerd op een anderr systeem) waarbij je op de rescue shell (in initramfs) wordt gedropt, je de import kunt forceren en weer verder kunt booten. Ik had nu daarbij een gewone reinstall gedaan (vanaf netinstall medium die Netcup netjes beschikbaar stelt, hoeft maar te klikken om die aan te koppelen) maar dan met de installatie op de laatste 10GB van de disk en de rest vrij. En vervolgens vanaf die installatie de "ZFS on root" stappen doorlopen. Faalde uiteraard nog steeds, maar het viel me toen wel op dat ook bij die installatie er na Grub geen beeld was, tot vervolgens even een korte flits wat leek op systemd direct gevolgd door de login prompt. Wat mij het idee gaf dat er puur geen beeld was in combinatie met de falende import. Dus vanaf die installatie een import (werkte direct, zonder te "forceren"), vervolgens de export, reboot, en tada, een login prompt vanaf de installatie op ZFS. En vervolgens die 10GB partitie verwijderd en de ZFS partitie groter gemaakt.

Alleen..., loop ik nu weer tegen een nieuw probleem aan Namelijk IPv6. Ze geven een /64 adres uit. Maar blijkbaar routeren ze niet de /64 naar de VPS . De VPS heb ik op de prefix maar /72 gezet. Dit geeft dus nog 8 bits om te segmenteren. Waardoor ik Docker met IPv6 kan gebruiken (in die 8 bits). Waarbij containers dus rechtstreeks aan het internet gehangen kunnen worden met een GUA adres. Alleen..., kan ik die containers niet eens pingen. Wat er blijkbaar, altijd, gebeurt is dat de router van Netcup een neigbor solicit ("ARP request" bij IPv4) de deur uit doet voor het "onbekende" IP adres. Alleen kan mijn VPS hier "niks mee". Want de "fysieke" interface heeft bv <prefix>::1. Maar mijn reverse proxy draait in een container op <prefix>:8000::80. Vervolgens komt er op de "fysieke" interface een neighbor solicit voor <prefix>:8000::80 waar de VPS niks mee kan, want dat IP adres kent hij niet, op de interface waarop de solicit binnen komt (/uberhaupt niet. Maar er is wel een bridge en een virtuele interface voor <prefix>::8000::/72). Dus daar antwoord die niet op.
Dus bv een ping naar dat IP adres resulteert in een router van Netcup die antwoord met een "Unreachable address". Terwijl bij Contabo dit prima werkt. Daar zal gewoon altijd de prefix gerouteerd worden. Dus gewoon alles van <prefix>::/64 gaat naar de VPS en die zoekt het zich maar uit wat die er mee doet. En naar mijn idee is dat ook een stuk logischer.
En waarschijnlijk is dat ook nog eens een stuk veiliger. Want ik nu met tcpdump ook solicits voorbij komen met IPv6 adressen (GUAs) die helemaal niet van mij zijm (met grapjes zoals "c0de:cafe" ). Dus waarschijnlijk kan ik mijn VPS ook laten antwoorden op zo'n IP (/gewoon dat IP statisch toekennen) en komt dat verkeer dan ineens op mijn VPS aan?!
Simpel te zien verschil tussen Contabo en Netcup is dan ook dat als ik bv <prefix>::2 ping, dat niet in gebruik is, ik bij Contabo een Unreachable address krijg van op <prefix>::1, mijn VPS, en bij Netcup een totaal ander IP (dat in een traceroute uiteraard direct voor mijn VPS zit (/laatste hop voor de VPS). En dus ook dat als ik een tcpdump draai bij Contabo mijn VPS (alleen) de echo request ontvangt, zelf op zoek gaat naar dat IP (zelf een neighbor solicit de deur uit doet) en dan ook zelf de Unreachable address de deur uit doet. Bij Netcup daarentegen resulteert die ping naar <prefix>::2 (alleen) in een neighbor solicit voor <prefix>::2. Waar de VPS (/geen enkele VPS) dus op reageert en de hop/router die de solicit doet dus de Unreachable stuurt.
Nu kan ik daarover wel weer contact opnemen hoe dat zit. Maar dan heb ik intussen toch zoiets van "waarom zou ik de moeite doen?", in combinatie met mijn vorige ticket dat dus nog steeds open staat. En de implicaties van dat de prefix niet direct aan de VPS is gekoppeld, maar het gebruik van een neighbor solicit, geven mij nu ook niet echt vertrouwen (als in: mogelijk om een IP uit andere prefix in/over te nemen?! ).

Maar, lang verhaal kort, ben ik nu wel benieuwd hoe het IPv6 stuk bij andere providers (Hetzner bv) in elkaar steekt. Wellicht dat anderen dus eens een ping kunnen doen naar een niet in gebruik zijnd IP binnen hun prefix, en aangeven of de "From ..." dan het IP adres van de VPS is of een ander IP adres (in een ander subnet).

[jurroen]

RobertMe schreef op zondag 23 maart 2025 @ 19:12:
[...]

Wellicht dat anderen dus eens een ping kunnen doen naar een niet in gebruik zijnd IP binnen hun prefix, en aangeven of de "From ..." dan het IP adres van de VPS is of een ander IP adres (in een ander subnet).

Bij een beetje provider gaat dit niet werken, want die hebben hun zaakjes wel op orde. Had een paar weken terug een VPS aangemaakt bij Netcup om arm64 port trees te compilen - maar wat een shitshow zeg.

Hetzner is misschien iets minder cheap in verhouding maar dat merk je dan ook wel terug IMHO. Betere klantenservice, zaken beter op orde etc.

[RobertMe]

jurroen schreef op zondag 23 maart 2025 @ 20:19:
[...]


Bij een beetje provider gaat dit niet werken, want die hebben hun zaakjes wel op orde.

Ik verwacht in zoverre ook niet dat het/iets werkt. Maar als de prefix a:b:c:d::/64 is en de VPS heeft IP a:b:c:d::1, en je doet "vanaf thuis" een ping naar a:b:c:d::2 dan zal er een "Unreachable address" / destination unreachable error zijn. Mijn vraag is dan "vanaf welk IP komt dat?" Is dat de eigen "a:b::d::1" of een ander adres?

V.w.b. Hetzner, iets duurder, en je krijgt minder Netcup ARM betaal je laag in de €7 en krijg je 6 cores en 256GB opslag. Bij Hetzner betaal je bijna €8 en krijg je 4 cores en ik meen nog geen 100GB opslag. Nee, ik heb het niet perse nodig. Bij Contabo nu ook 4 cores, en meen 50GB opslag.

[jurroen]

RobertMe schreef op zondag 23 maart 2025 @ 20:55:
[...]

V.w.b. Hetzner, iets duurder, en je krijgt minder Netcup ARM betaal je laag in de €7 en krijg je 6 cores en 256GB opslag. Bij Hetzner betaal je bijna €8 en krijg je 4 cores en ik meen nog geen 100GB opslag. Nee, ik heb het niet perse nodig. Bij Contabo nu ook 4 cores, en meen 50GB opslag.

Je krijgt wellicht minder resources. Maar daarentegen is er een klantenservice, goed netwerk en een aanbieder die z'n zaakjes beter op orde heeft. Dat telt in mijn ogen ook.

Bij Oracle krijg je 6 ARM cores en 24GB RAM. Voor welgeteld € 0. Goedkoper gaat niet - want geen provider die jou geld gaat geven

Maar goed - de ene core is de andere niet - net zoals dat aanbieders niet open zijn over de IOPS die ze aanbieden

[bart.koppers]

RobertMe schreef op zondag 23 maart 2025 @ 20:55:
[...]

Ik verwacht in zoverre ook niet dat het/iets werkt. Maar als de prefix a:b:c:d::/64 is en de VPS heeft IP a:b:c:d::1, en je doet "vanaf thuis" een ping naar a:b:c:d::2 dan zal er een "Unreachable address" / destination unreachable error zijn. Mijn vraag is dan "vanaf welk IP komt dat?" Is dat de eigen "a:b::d::1" of een ander adres?

Ping vanaf thuis kan …… ::2 niet bereiken.
Want tenzij je dat adres ook hebt gekoppeld aan je VPS, en hebt gerouteerd cq announced weet niemand hoe dat …:2 te bereiken.

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 01:03:
[...]

Ping vanaf thuis kan …… ::2 niet bereiken.

No shit Daarom vraag ik okm welke host de error geeft. En niet of er een error is. Dat er een error is weet ik ook wel met 100 zekerheid. Alleen wordt bij Contabo de error door mijn VPS gegeven (hele /64 gaat naar de VOS, die ::2 niet kent en errort), en bij Netcup door een router van hun (die ::2 nergens kan vinden in het hele netwerk, omdat geen enkele VPS deze advertised op de solicit van die router). En naar mijn idee "hoort" de error dus vanaf mijn VPS te komen. Als in: de provider die de hele /64 naar de VPS stuurt en de VPS het laat uitzoeken. Waarbij ik mij ook serieus afvraag of ik bij Netcup niet gewoon een IP adres kan claimen buiten mijn subnet (en niet in gebruik is) waarvoor ik wel solicits langs zie komen. Dan kan ik dus zomaar verkeer naar een andere VPS over nemen. Of een of andere rogue neighbor discovery implementatie die op elke solicit een advertise stuurt dat mijn VPS dat IP heeft. Dan kan dus niemand meer een IP adres gebruiken omdat ze allemaal in gebruik zijn

[bart.koppers]

RobertMe schreef op maandag 24 maart 2025 @ 06:42:
[...]

No shit Daarom vraag ik okm welke host de error geeft. En niet of er een error is. Dat er een error is weet ik ook wel met 100 zekerheid. Alleen wordt bij Contabo de error door mijn VPS gegeven (hele /64 gaat naar de VOS, die ::2 niet kent en errort), en bij Netcup door een router van hun (die ::2 nergens kan vinden in het hele netwerk, omdat geen enkele VPS deze advertised op de solicit van die router). En naar mijn idee "hoort" de error dus vanaf mijn VPS te komen. Als in: de provider die de hele /64 naar de VPS stuurt en de VPS het laat uitzoeken. Waarbij ik mij ook serieus afvraag of ik bij Netcup niet gewoon een IP adres kan claimen buiten mijn subnet (en niet in gebruik is) waarvoor ik wel solicits langs zie komen. Dan kan ik dus zomaar verkeer naar een andere VPS over nemen. Of een of andere rogue neighbor discovery implementatie die op elke solicit een advertise stuurt dat mijn VPS dat IP heeft. Dan kan dus niemand meer een IP adres gebruiken omdat ze allemaal in gebruik zijn

Ik ken Contabo niet met ipv6.

Meestal krijg je een /48 of een /56 subnet van de leverancier
Dan moet je VPS daar uiteraard op ingesteld zijn.

Ping naar ::2 vanaf de VPS zelf werkt dus wel?

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 08:46:
[...]


Ik ken Contabo niet met ipv6.

Meestal krijg je een /48 of een /56 subnet van de leverancier
Dan moet je VPS daar uiteraard op ingesteld zijn.

Ping naar ::2 vanaf de VPS zelf werkt dus wel?

Uiteraard werkt ping vanaf de VPS zelf ook niet. Maar punt is dat verkeer überhaupt niet bij de VPS aan komt.

Ik krijg zowel bij Contabo als Netcup een /64. Echter gebruik ik op de "fysieke" interface een /72. Vervolgens gebruik ik Docker met IPv6 waarbij ik dus 8 bits (/64 vs /72) heb om Docker bridges GUAs te geven. Alleen komt bij Netcup dat verkeer dus niet aan. Als ik a:b:c:d::/64 als prefix heb dan heb ik bv op a:b:c:d:8000::443 een HTTP server draaien, in Docker. Bij Contabo werkt dit out of the box prima. Verkeer naar de a:b:c:d::/64 prefix wordt altijd naar mijn VPS gestuurd, en de VPS kent a:b:c:d:8000::/72 want hij heeft zelf een bridge met adres a:b:c:d:8000::1/72 (+ dus een route dat a:b:c:d:8000::/72 direct bereikbaar is op die bridge). Bij Netcup werkt dit echter niet. Want die sturen niet alle verkeer van a:b:c:d::/64 naar de VPS. Maar die sturen in de plaats een neighbor solicit voor a:b:c:d:8000::443. Echter is er geen enkel systeem (en dus ook mijn VPS niet) die reageert op die solicit. Immers is er geen enkel "direct bereikbaar" systeem met dat IP adres. Mijn VPS zou het door hoepels heen wel kennen, maar moet daarvoor over een bridge heen, en dat is dus weer niet de bedoeling van solicits. De solicit is immers een ARP opvolger (/IPv6s variant van IPv4s ARP) en hoort dus niet over routers heen te gaan. Maar volgens mij zijn er wel userspace implementaties voor neighbor discovery die het wel relayen.

Oftewel: bij Contabo ligt er in hun router een route vast dat de volledige /64 naar mijn VPS gestuurd moet worden. En wat mijn VPS daar mee doet moet die zelf weten. En dat dit het geval is is dus simpel te bewijzen door een ping te doen naar een niet gebruikt IP adres binnen de prefix, de error is dan afkomstig van mijn VPS. Bij Netcup echter wordt niet de volledige /64 naar mijn VPS gestuurd (maar wordt in de plaats een solicit gedaan binnen het hele netwerk (case in point: ik zie ook de meest willekeurige solicits voor andere prefixes voorbij komen, "continu")), waardoor ik dus geen volledige controle heb over welke IPs ik waar gebruik. En dezelfde test (ping naar niet gebruikt IP binnen de prefix) bewijst dit doordat de error afkomstig is van een Netcup router (als ik een traceroute doe (naar het in gebruik zijnde IP ) is het IP dat de error stuurt dus dat van de laatste hop voor de VPS), en daarnaast een tcpdump dus een solicit laat zien voor dat IP adres.

[bart.koppers]

RobertMe schreef op maandag 24 maart 2025 @ 09:27:
[...]

Uiteraard werkt ping vanaf de VPS zelf ook niet. Maar punt is dat verkeer überhaupt niet bij de VPS aan komt.

Ik krijg zowel bij Contabo als Netcup een /64. Echter gebruik ik op de "fysieke" interface een /72. Vervolgens gebruik ik Docker met IPv6 waarbij ik dus 8 bits (/64 vs /72) heb om Docker bridges GUAs te geven. Alleen komt bij Netcup dat verkeer dus niet aan. Als ik a:b:c:d::/64 als prefix heb dan heb ik bv op a:b:c:d:8000::443 een HTTP server draaien, in Docker. Bij Contabo werkt dit out of the box prima. Verkeer naar de a:b:c:d::/64 prefix wordt altijd naar mijn VPS gestuurd, en de VPS kent a:b:c:d:8000::/72 want hij heeft zelf een bridge met adres a:b:c:d:8000::1/72 (+ dus een route dat a:b:c:d:8000::/72 direct bereikbaar is op die bridge). Bij Netcup werkt dit echter niet. Want die sturen niet alle verkeer van a:b:c:d::/64 naar de VPS. Maar die sturen in de plaats een neighbor solicit voor a:b:c:d:8000::443. Echter is er geen enkel systeem (en dus ook mijn VPS niet) die reageert op die solicit. Immers is er geen enkel "direct bereikbaar" systeem met dat IP adres. Mijn VPS zou het door hoepels heen wel kennen, maar moet daarvoor over een bridge heen, en dat is dus weer niet de bedoeling van solicits. De solicit is immers een ARP opvolger (/IPv6s variant van IPv4s ARP) en hoort dus niet over routers heen te gaan. Maar volgens mij zijn er wel userspace implementaties voor neighbor discovery die het wel relayen.

Oftewel: bij Contabo ligt er in hun router een route vast dat de volledige /64 naar mijn VPS gestuurd moet worden. En wat mijn VPS daar mee doet moet die zelf weten. En dat dit het geval is is dus simpel te bewijzen door een ping te doen naar een niet gebruikt IP adres binnen de prefix, de error is dan afkomstig van mijn VPS. Bij Netcup echter wordt niet de volledige /64 naar mijn VPS gestuurd (maar wordt in de plaats een solicit gedaan binnen het hele netwerk (case in point: ik zie ook de meest willekeurige solicits voor andere prefixes voorbij komen, "continu")), waardoor ik dus geen volledige controle heb over welke IPs ik waar gebruik. En dezelfde test (ping naar niet gebruikt IP binnen de prefix) bewijst dit doordat de error afkomstig is van een Netcup router (als ik een traceroute doe (naar het in gebruik zijnde IP ) is het IP dat de error stuurt dus dat van de laatste hop voor de VPS), en daarnaast een tcpdump dus een solicit laat zien voor dat IP adres.

Als je vps niet eens antwoordt op de pung, dan begrijp ik niet waarom je verwacht dat je een reply van buiten krijgt - maar dat terzijde.

De implementatie van Netcup lijkt me meer te kloppen dan het soort van forward-gedrag dat jij ziet bij Contabo.

Denk dat je eerst de ip’s moet toewijzen in de vps, evt ndp inzetten

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 09:40:
[...]


Als je vps niet eens antwoordt op de pung, dan begrijp ik niet waarom je verwacht dat je een reply van buiten krijgt - maar dat terzijde.

De implementatie van Netcup lijkt me meer te kloppen dan het soort van forward-gedrag dat jij ziet bij Contabo.

Denk dat je eerst de ip’s moet toewijzen in de vps, evt ndp inzetten

Ik kan het IP niet toewijzen op de VPS. Ja, het voorbeeld van die ::2 wel natuurlijk. Maar niet de <prefix>:8000::443. Want de "fysieke" interface zit op <prefix>::1/72. Dus <prefix>:8000::443 valt helemaal niet binnen het subnet van de interface. En daarna is er dus een bridge waar <prefix>:8000::1/72 op zit. Dus ik kan niet eens op een andere interface <prefix>:8000:... gebruiken want dan overlappen de subnets.

Edit/aanvulling:
Overigens speelt het probleem ook niet alleen bij Docker. Hetzelfde zou ook gebeuren als je bv een Wireguard VPN er op wilt zetten en daarbii gebruik maken van de GUA prefix (zodat clients een IP binnen die prefix hebben etc). Dan heeft de Wireguard interface ook een eigen subnet nodig. Dus het opslitsen van de /64 prefix nodig. Waarbij bij Netcup het verkeer naar die "onbekende" IPs ook niet naar de VPS gaat terwijl het bij Contabo prima zou werken omdat daar wel het verkeer naar de volledige /64 wordt doorgezet naar de VPS, onafhankelijk van wat de VPS adverteert.

En eigenlijk is het ook niet heel anders dan hoe ISPs werken. Bij Ziggo heeft mijn router een IPv6 adres in een totaal ander subnet dan dat wat via DHCP-PD verkregen wordt. En Ziggo heeft 0,0 informatie over welke IPv6 adressen door mij gebruikt worden (binnen die prefix). Toch kunnen ze prima alle verkeer gericht aan de /56 prefix prima afleveren bij mijn router. En vervolgens mag de router zelf uitzoeken wat verder met dat verkeer gebeurt. Exact hetzelfde dus als dat mijn Contabo VPS prima zelf mag uitzoeken wat met het verkeer gericht aan de prefix gebeurt. Terwijl bij Netcup het verkeer helemaal niet op de VPS aan komt (tsnzij de neighbor solicit een antwoord oplevert).

[ Voor 42% gewijzigd door RobertMe op 24-03-2025 10:02 ]

[bart.koppers]

RobertMe schreef op maandag 24 maart 2025 @ 09:45:
[...]

Ik kan het IP niet toewijzen op de VPS. Ja, het voorbeeld van die ::2 wel natuurlijk. Maar niet de <prefix>:8000::443. Want de "fysieke" interface zit op <prefix>::1/72. Dus <prefix>:8000::443 valt helemaal niet binnen het subnet van de interface. En daarna is er dus een bridge waar <prefix>:8000::1/72 op zit. Dus ik kan niet eens op een andere interface <prefix>:8000:... gebruiken want dan overlappen de subnets.

Edit/aanvulling:
Overigens speelt het probleem ook niet alleen bij Docker. Hetzelfde zou ook gebeuren als je bv een Wireguard VPN er op wilt zetten en daarbii gebruik maken van de GUA prefix (zodat clients een IP binnen die prefix hebben etc). Dan heeft de Wireguard interface ook een eigen subnet nodig. Dus het opslitsen van de /64 prefix nodig. Waarbij bij Netcup het verkeer naar die "onbekende" IPs ook niet naar de VPS gaat terwijl het bij Contabo prima zou werken omdat daar wel het verkeer naar de volledige /64 wordt doorgezet naar de VPS, onafhankelijk van wat de VPS adverteert.

En eigenlijk is het ook niet heel anders dan hoe ISPs werken. Bij Ziggo heeft mijn router een IPv6 adres in een totaal ander subnet dan dat wat via DHCP-PD verkregen wordt. En Ziggo heeft 0,0 informatie over welke IPv6 adressen door mij gebruikt worden (binnen die prefix). Toch kunnen ze prima alle verkeer gericht aan de /56 prefix prima afleveren bij mijn router. En vervolgens mag de router zelf uitzoeken wat verder met dat verkeer gebeurt. Exact hetzelfde dus als dat mijn Contabo VPS prima zelf mag uitzoeken wat met het verkeer gericht aan de prefix gebeurt. Terwijl bij Netcup het verkeer helemaal niet op de VPS aan komt (tsnzij de neighbor solicit een antwoord oplevert).

Maar deels zeg je het zelf al via de verwijzing hoe eea gaat bij een Ziggo-verbinding: er is ergens een routeer(functie) nodig.
Ziggo configureert je router en deelt de adressen uit.

Maar dat werkt niet altijd of zomaar zo in je vps. Die moet je ervoor configureren.
Ik weet niet of je dat allemaal al gedaan hebt.

Bv dhcp-d is niet standaard actief voor ipv6 in je vps
(al kan het dat Netcup dat toestaat in te regelen - zie onder)
Ipv6 kan/moet uitgedeeld, of toegewezen, net als gateway en DNS

De ipv6 adressen die je wil bereiken moeten dus (eerst) aan de vps host gekoppeld zijn (in het OS)

Dat kan aan een bridge.
Of op een interface aan de bridge.

Soms gaat dit via een (web)configuratie die de hoster aanbiedt (zodat bv via dhcp6 kan verlopen), soms kan het alleen maar door IPv6 fixed op OS-level te configureren.

Vele opties en vele smaakjes linux, dus ik heb geen magic bullet.

Maar valt te proberen eerst met bv 2x een /64 ip werkend te krijgen.
Die je dan beide moet kunnen pingen.

Haal docker er even tussenuit.
Docker forward/bindt zoals je ongetwijfeld weet naar/tussen poortjes en (interne) IP-adressen.
Die moeten wel eerst bereikbaar zijn.
(zelf gebruik ik geen docker/ipv6 in combinatie op vps, alleen ipv4 ivm firewalling - dus daar weet je denk ik dan meer van dan ik)

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 11:27:
[...]


Maar deels zeg je het zelf al via de verwijzing hoe eea gaat bij een Ziggo-verbinding: er is ergens een routeer(functie) nodig.
Ziggo configureert je router en deelt de adressen uit.

Ik draai mijn eigen router en het Ziggo modem staat in bridge. Enige dat Ziggo dus weet is welke prefix zij mij hebben toegekend Verder weten ze daar helemaal niks van.

Maar dat werkt niet altijd of zomaar zo in je vps. Die moet je ervoor configureren.
Ik weet niet of je dat allemaal al gedaan hebt.

Bv dhcp-d is niet standaard actief voor ipv6 in je vps
(al kan het dat Netcup dat toestaat in te regelen - zie onder)
Ipv6 kan/moet uitgedeeld, of toegewezen, net als gateway en DNS

Netcup geeft gewoon aan welke prefix je hebt/is toegewezen. Deze kan dan als static worden gebruikt op de VPS. Daarnaast geven ze uiteraard ook de te gebruiken gateway aan.

De ipv6 adressen die je wil bereiken moeten dus (eerst) aan de vps host gekoppeld zijn (in het OS)

Naar mijn idee dus niet, en bij Contabo ook niet nodig. Waar Netcup (/de hosting provider) voor moet zorgen is dat de prefix waarvan ze zeggen dat dat die "van mij" is ook wordt afgeleverd. Welke IP adressen ik vervolgens daadwerkelijk toeken en hoe ik de rest inricht (of ik het in kleinere subnets bv verdeel) is voor hun in principe niet relevant.

Dat kan aan een bridge.
Of op een interface aan de bridge.

Er is geen bridge op de fysieke interface. En noch de fysieke interface noch een hypothetische bridge waar die interface in zit kan in de geschetste scenario's "het IP adres" hebben. Want dat IP adres zit in een ander subnet, én zou leiden tot overlappende subnets.

Maar valt te proberen eerst met bv 2x een /64 ip werkend te krijgen.
Die je dan beide moet kunnen pingen.

Als het IP adres op de fysieke interface geconfigureerd is werkt het uiteraard prima. Netcup stuurt een neighbor solicit en de VPS reageert daaro. Immers heeft die dat IP adres op de interface (/in het broadcast domain) waarop de solicit binnen komt. Echter werkt dat dus niet als het IP adres, volledig valide, op een andere interface, en dus ander broadcast domain, is ingesteld. Een neigbor solicit is immers niet routeerbaar.

Haal docker er even tussenuit.
Docker forward/bindt zoals je ongetwijfeld weet naar/tussen poortjes en (interne) IP-adressen.
Die moeten wel eerst bereikbaar zijn.
(zelf gebruik ik geen docker/ipv6 in combinatie op vps, alleen ipv4 ivm firewalling - dus daar weet je denk ik dan meer van dan ik)

Met IPv6 zijn "(interne) adressen" redelijk not done. Immers geeft een /96 subnet al net zoveel mogelijke IP adressen als IPv4, en je krijgt ook nog eens een /64, dus nog veel en veel meer mogelijkheden. NAT / masquarading hoort dus helemaal niet thuis in een IPv6 wereld. En zelfs de Docker documentatie maakt gebruik van 2001:db8:..., dat gereserveerd is voor documentatie en valt onder de GUA (lees: publieke) adressen. Port forwarding (/DNAT) is dus niet nodig, enige dat nodig is is het toestaan om het verkeer (1-op-1) te forwarden. (Daar waar bij IPv4 dus destination nat wordt toegepast om het destination IP (en evt poort) te wijzigen, en het verkeer daarnaast ook bestemd is aan het publieke IPv4 adres (van de server), en bij IPv6 aan het GUA adres van de container).

[3raser]

Ik denk dat je voor deze discussie beter een apart topic aan kan maken want dit lijkt me meer een losse hoe-werkt-IPv6 discussie dan iets wat daadwerkelijk met het opzetten van een VPS te maken heeft.

[bart.koppers]

3raser schreef op maandag 24 maart 2025 @ 11:58:
Ik denk dat je voor deze discussie beter een apart topic aan kan maken want dit lijkt me meer een losse hoe-werkt-IPv6 discussie dan iets wat daadwerkelijk met het opzetten van een VPS te maken heeft.

Deels mee eens hoor.

Het is voornamelijk een zaak van juiste netwerkconfiguratie op de vps en door de hoster.

Geeft wel goed weer dat ipv6 op een vps zo zijn uitdagingen kent. Per hoster is dat nu eenmaal verschillend.

[RobertMe]

3raser schreef op maandag 24 maart 2025 @ 11:58:
Ik denk dat je voor deze discussie beter een apart topic aan kan maken want dit lijkt me meer een losse hoe-werkt-IPv6 discussie dan iets wat daadwerkelijk met het opzetten van een VPS te maken heeft.

Je wilt zeggen dat hoe een hosting provider een IPv6 subnet toekent en routeert naar een VPS (met in ieder geval een prefix administratief toegekend / gecommuniceerd naar de klant) niks met VPS ervaringen te maken heeft?

Ik weet prima hoe het op te zetten. Anders had ik het niet al jaren werkende bij Contabo.

En ik had ook al in RobertMe in "Het grote IPv6 topic" gepost. Met in ieder geval 1 reactie "die het met mij eens is" (dat ze gewoon de hele prefix naar mijn VPS moeten sturen het de rest aan de VPS over laten).

En ik was ook meer benieuwd naar ervaringen met andere providers. Waarbij afgaande op een reactie van @Noahlvb bij Liteserver in het control panel (specifieke) adressen opgevoerd kunnen worden om te routeren naar de VPS. Ook nogal onhandig, maar nog steeds beter dan Netcup waar het semi onmogelijk is om het voor elkaar te krijgen.

[3raser]

Ik heb geen ervaring met Netcup, maar bij Hetzner lijk ik het adres eerst toe te moeten voegen aan de VPS (via het controlpanel) om deze te kunnen bereiken.

[RobertMe]

3raser schreef op maandag 24 maart 2025 @ 13:41:
Ik heb geen ervaring met Netcup, maar bij Hetzner lijk ik het adres eerst toe te moeten voegen aan de VPS (via het controlpanel) om deze te kunnen bereiken.

Ik kan bij Netcup nog wel eens testen met het reverse DNS stukje (bij IPv6 "oneindig" IPs + domeinnaam toevoegen). Maar gezien de neighbor solicit (te zien met tcpdump) en het ip addr add ... van bv de ::2 dan prima werkt (zonder verdere aanpassingen) heb ik er een hard hoofd in dat het "control panel config" gebaseerd.

Met de hand opvoeren is beetje ~ meh ~, maar werkt vast beter dan Netcup nu waar het heel iffy is.

En dan denk ik dat ik vanavond ook meteen de VPS cancel in combinatie met het hele verhaal. Ook internet snelheid, trage ping, slechte support, .... Maar heb nu in ieder geval wat meer informatie van andere partijen.

[RobertMe]

Zojuist de (Netcup) VPS opgezegd (kon nog binnen de "[30 dagen] niet goed geld terug" garantie). rDNS stukje heb ik niet meer getest, zag wel bij opzeggen dat in het customer control panel (www.customercontrolpanel.de) dat het daar ook echt expliciet rDNS heet (i.t.t. het server control panel, op www.servercontrolpanel.de, wat een puinzooi met losse systemen en domeinen die ook nog eens een eigen login hebben (maar zag nu wel een single-sign-on van het CCP naar het SCP)). En nouja, rDNS heeft vrij weinig met routing te maken.

Maar ik had het wel nog aan de praat gekregen, op twee manieren zelfs: RobertMe in "Het grote IPv6 topic" . De VPS laten antwoorden op de neighbor solicit dus, of op basis van de Linux kernel implementatie, of op basis van (een van de) user space proxies.

Alleen vind ik het vrij schrikbarend dat dus potentieel ik kan reageren op NDP solicits behorende tot andere prefixes en ik op die manier dus potentieel het IP adres van een andere klant kan "over nemen" . Ook gecombineerd dus met het feit dat ik uberhaupt in no-time met een tcpdump een tiental NDP solicits per seconde voorbij zie komen. Wat mij ook een slecht gevoel geeft omtrent "security" en hoe de VPSen onderling (niet) gescheiden zijn. Want doe ik hetzelfde op mijn Contabo VPS, dan gebeurt er gewoon "niks". Komt geen enkel NDP verkeer voorbij. Staat intussen minuutje (/minuten?) te tcpdumpen en 0 icmp6 verkeer en dus ook geen NDP solicits.

[idef1x]

Iemand hier toevallig ervaring met avoro.eu? Ziet er op zich best schappelijk uit.
Zit nu met tevredenheid bij Hetzner, maar heb eigenlijk net iets meer nodig en dan betaal je gelijk het dubbele zowat. Contabo is qua performance niet het je van het gebleken, dus zoek eigenlijk nog een alternatief

[jurroen]

idef1x schreef op donderdag 8 mei 2025 @ 08:56:
Iemand hier toevallig ervaring met avoro.eu? Ziet er op zich best schappelijk uit.
Zit nu met tevredenheid bij Hetzner, maar heb eigenlijk net iets meer nodig en dan betaal je gelijk het dubbele zowat. Contabo is qua performance niet het je van het gebleken, dus zoek eigenlijk nog een alternatief

De site geeft enorm de indruk dat ze een reseller zijn van een andere partij. Maar blijkbaar is Avoro sen handelsnaam van het Duitse dataforest GmbH. Ze hebben hun netwerk en peering wel enigszins op orde. Wel een beetje maf dat Avoro achter CloudFlare hangt.

Lees dat ze DTAG gebruiken. Mocht jouw Tier 1 iets van NTT/GTT zijn kan dat met momenten wat ruk zijn, ligt meen ik bij de DTAG kant en is men mee bezig.

Zou zeggen, neem er wat af en deel de resultaten vooral. Voor die prijzen hoef je het niet te laten

[jurroen]

Oh eh even wat verder gekeken, ze lijken ook wat offshore te zijn (betalingen in cryptovaluta etc). Enige voorzichtigheid is wel aan te bevelen.

[idef1x]

Dank voor de terugkoppeling. Denk dat ik maar gewoon bij Hetzner blijf..Een VPS voldoende voor me in Helsinki is wat goedkoper, dan Nuremburg...eens zien of de hogere latency echt impact heeft...denk het niet want nextcloud is niet zo netwerk latency gevoelig voor mijn doel ;-)

[rcthans]

Ik ben helemaal nieuw in de hosting/VPS/server en netwerk wereld.


Ik heb een server bij hetzner met veel TB aan storage. Maar daar kan ik geen plex hosten, want plex blokkeert al de ip's van hetzner. Ik ben nu al twee dagen bezig met het volgende

https://gist.github.com/s...33f3d8764c5dc36e19ff5d0aa

En heb het voor elkaar gekregen. Plex media server in een docker compose, samen met wireguard op de ubuntu server bij hetzner. Deze staat in verbinding met wireguard op een VPS die ik bij Strato heb gehuurd. (STRATO VPS Linux VC4-8 (1.nl))

Nu heb ik het volgende probleem. Ik krijg op geen enkele manier meer dan +- 200 Mbps door de tunnel heen. Het gaat om UDP plex traffic. Op de vps haalt een speedtest 1gb+, mijn hetzner haalt dat ook.

Is er een limiet op udp verkeer met zon strato VPS? Is het docker? is het de MTU size die niet goed ingesteld is op client of server?



Bij strato staat overigens dit bij de specs,

Netwerkverbinding
tot 1.000 Mbit/s

[DutchKel]

rcthans schreef op woensdag 21 mei 2025 @ 04:47:
Ik ben helemaal nieuw in de hosting/VPS/server en netwerk wereld.


Ik heb een server bij hetzner met veel TB aan storage. Maar daar kan ik geen plex hosten, want plex blokkeert al de ip's van hetzner. Ik ben nu al twee dagen bezig met het volgende

https://gist.github.com/s...33f3d8764c5dc36e19ff5d0aa

En heb het voor elkaar gekregen. Plex media server in een docker compose, samen met wireguard op de ubuntu server bij hetzner. Deze staat in verbinding met wireguard op een VPS die ik bij Strato heb gehuurd. (STRATO VPS Linux VC4-8 (1.nl))

Nu heb ik het volgende probleem. Ik krijg op geen enkele manier meer dan +- 200 Mbps door de tunnel heen. Het gaat om UDP plex traffic. Op de vps haalt een speedtest 1gb+, mijn hetzner haalt dat ook.

Is er een limiet op udp verkeer met zon strato VPS? Is het docker? is het de MTU size die niet goed ingesteld is op client of server?

[Afbeelding]

[Afbeelding]

Bij strato staat overigens dit bij de specs,

Netwerkverbinding
tot 1.000 Mbit/s

Niet zo ingewikkeld doen en gewoon https://emby.media/ gebruiken.

[bart.koppers]

rcthans schreef op woensdag 21 mei 2025 @ 04:47:
Ik ben helemaal nieuw in de hosting/VPS/server en netwerk wereld.

Extra kudos dat je het voor elkaar krijgt!

Nu heb ik het volgende probleem. Ik krijg op geen enkele manier meer dan +- 200 Mbps door de tunnel heen. Het gaat om UDP plex traffic. Op de vps haalt een speedtest 1gb+, mijn hetzner haalt dat ook.

Is er een limiet op udp verkeer met zon strato VPS? Is het docker? is het de MTU size die niet goed ingesteld is op client of server?

[Afbeelding]

[Afbeelding]

Bij strato staat overigens dit bij de specs,

Netwerkverbinding
tot 1.000 Mbit/s

Waar draait de Plex server zelf?
Daar op ingesteld dat het vpn/Wireguard netwerk als lokaal/LAN moet worden beschouwd?

[3raser]

rcthans schreef op woensdag 21 mei 2025 @ 04:47:
Ik ben helemaal nieuw in de hosting/VPS/server en netwerk wereld.


Ik heb een server bij hetzner met veel TB aan storage. Maar daar kan ik geen plex hosten, want plex blokkeert al de ip's van hetzner. Ik ben nu al twee dagen bezig met het volgende

https://gist.github.com/s...33f3d8764c5dc36e19ff5d0aa

En heb het voor elkaar gekregen. Plex media server in een docker compose, samen met wireguard op de ubuntu server bij hetzner. Deze staat in verbinding met wireguard op een VPS die ik bij Strato heb gehuurd. (STRATO VPS Linux VC4-8 (1.nl))

Nu heb ik het volgende probleem. Ik krijg op geen enkele manier meer dan +- 200 Mbps door de tunnel heen. Het gaat om UDP plex traffic. Op de vps haalt een speedtest 1gb+, mijn hetzner haalt dat ook.

Is er een limiet op udp verkeer met zon strato VPS? Is het docker? is het de MTU size die niet goed ingesteld is op client of server?

[Afbeelding]

[Afbeelding]

Bij strato staat overigens dit bij de specs,

Netwerkverbinding
tot 1.000 Mbit/s

Heb je al eens geprobeerd om een speedtest te doen op je Strato server door middel van het downloaden van een groot bestand bij Hetzner? Hier kun je bestanden vinden om de snelheid te testen: Datacenter in Falkenstein, en Nuremberg.

[rcthans]

Speedtest is netjes 1000Mbps, maar denk ik nou heel gek als ik zeg. Dat je met mijn usecase. Op zon virtuele 1gb vps verbinding nooit meer dan 500 throughput gaat krijgen? 500 in vanaf hetzner. 500 output naar plex clients.

Er staat nergens iets over full duplex. Morgen verder. Zelfde setup met mijn verbinding thuis proberen. (5gb full duplex )Dan weet ik snel genoeg of het aan de vps ligt

Strato
Netwerkverbinding
tot 1.000 Mbit/s

[3raser]

@rcthans Ik heb nog nooit gehoord van aanbieders die hun netwerk 1000Mbps noemen om vervolgens aan te geven dat het niet full duplex is. Dus dat lijkt me heel sterk.

[rcthans]

Om nog even terug te komen. Heb er een transip VPS bijgenomen om te testen, maar daar is het niet beter.
Het zal toch ergens aan mijn workflow/docker/plex/wireguard setup liggen. Maar lees ook veel dat UDP pakketen sowieso overal gelimiteerd worden, zeker op de goedkopere vps diensten.

Hoe dan ook, ik kan er prima plex mee kijken.



Strato VPS
Download: 201.01 Mbps (data used: 259.0 MB)
Upload: 215.77 Mbps (data used: 323.5 MB)
57.48 ms (jitter: 25.07ms, low: 17.52ms, high: 663.72ms)
Packet Loss: 4.2%


transip (blade vps)
Download: 199.81 Mbps (data used: 275.2 MB)
Upload: 179.63 Mbps (data used: 217.6 MB)
109.57 ms (jitter: 48.07ms, low: 14.26ms, high: 1042.39ms)
Packet Loss: 11.1%


*
Na uren lezen en proberen. Lijkt dit toch ook wel redelijk de limiet van een wireguard tunnel met deze latency. Het blijkt dat je in zulke gevallen het beste nodes zo dicht bij elkaar wilt hebben. Elke 10ms kan je al 10/20mbps kosten. Wist ik niet!

Next stop

Tailscale, of Cloudflared eens proberen:)

*
Edit 2

Fixed!! Er zijn meerdere tools om udp als tcp te faken.
Udp2raw is er eentje (600mbps) Pantun is nog beter (750mbps) en nu loop ik tegen mijn vps limiet aan (cpu).

Finally!!


https://github.com/dndx/p...calculation-for-wireguard

[ Voor 22% gewijzigd door rcthans op 22-05-2025 08:15 ]

[3raser]

rcthans schreef op donderdag 22 mei 2025 @ 07:04:
Om nog even terug te komen. Heb er een transip VPS bijgenomen om te testen, maar daar is het niet beter.
Het zal toch ergens aan mijn workflow/docker/plex/wireguard setup liggen. Maar lees ook veel dat UDP pakketen sowieso overal gelimiteerd worden, zeker op de goedkopere vps diensten.

Hoe dan ook, ik kan er prima plex mee kijken.

[Afbeelding]

Strato VPS
Download: 201.01 Mbps (data used: 259.0 MB)
Upload: 215.77 Mbps (data used: 323.5 MB)
57.48 ms (jitter: 25.07ms, low: 17.52ms, high: 663.72ms)
Packet Loss: 4.2%


transip (blade vps)
Download: 199.81 Mbps (data used: 275.2 MB)
Upload: 179.63 Mbps (data used: 217.6 MB)
109.57 ms (jitter: 48.07ms, low: 14.26ms, high: 1042.39ms)
Packet Loss: 11.1%


*
Na uren lezen en proberen. Lijkt dit toch ook wel redelijk de limiet van een wireguard tunnel met deze latency. Het blijkt dat je in zulke gevallen het beste nodes zo dicht bij elkaar wilt hebben. Elke 10ms kan je al 10/20mbps kosten. Wist ik niet!

Next stop

Tailscale, of Cloudflared eens proberen:)

*
Edit 2

Fixed!! Er zijn meerdere tools om udp als tcp te faken.
Udp2raw is er eentje (600mbps) Pantun is nog beter (750mbps) en nu loop ik tegen mijn vps limiet aan (cpu).

Finally!!


https://github.com/dndx/p...calculation-for-wireguard

Dat van die latency met vertraging vind ik een bijzonder verhaal. UDP is een protocol zonder controle en wordt dus juist gebruikt om op hoge snelheid data door te pompen. Bovendien is de gemiddelde latency in je test "maar" ~60ms bij Strato. Dat zou dus hooguit een vertraging van zo'n 120Mbps op kunnen leveren, en op 1Gbps zou je dan dus nog steeds aanzienlijk hogere snelheden moeten halen.

Het lijkt er eerder op dat de providers UDP verkeer knijpen aangezien je wel hogere snelheden krijgt als je het faket.

[Ebbez]

rcthans schreef op woensdag 21 mei 2025 @ 04:47:
Ik ben helemaal nieuw in de hosting/VPS/server en netwerk wereld.


Ik heb een server bij hetzner met veel TB aan storage. Maar daar kan ik geen plex hosten, want plex blokkeert al de ip's van hetzner. Ik ben nu al twee dagen bezig met het volgende

Ik heb zoiets soortgelijks ook gedaan, maar dan met JellyFin, een open-source alternatief voor Plex. Echter, ik zou wel goed nadenken over wat je nu doet. Zoals ik begrijp host je de media op de Hetzner storage? Als dit auteursrechtelijk beschermd materiaal is, dan kan het zo zijn dat wanneer je het deelt of de content komt perongeluk publiekelijk beschikbaar dat je dan toch wel aardig in de problemen komt. Aangezien de servers in Duitsland (waarschijnlijk? kan ook Helsinki zijn) staan, en we weten hoe streng ze in Duitsland de auteursrecht handhaven is het misschien niet heel slim, tenzij het misschien nog onder de Thuiskopieregeling valt. Ik ben er snel mee gestopt, want ik vond het een te groot risico.

[treative]

rcthans schreef op donderdag 22 mei 2025 @ 07:04:
...

Next stop

Tailscale, of Cloudflared eens proberen:)
...

Tailscale maakt gebruik van Wireguard, dus dat zal niet veel verschillen.

[3raser]

Ebbez schreef op donderdag 22 mei 2025 @ 13:12:
[...]


Ik heb zoiets soortgelijks ook gedaan, maar dan met JellyFin, een open-source alternatief voor Plex. Echter, ik zou wel goed nadenken over wat je nu doet. Zoals ik begrijp host je de media op de Hetzner storage? Als dit auteursrechtelijk beschermd materiaal is, dan kan het zo zijn dat wanneer je het deelt of de content komt perongeluk publiekelijk beschikbaar dat je dan toch wel aardig in de problemen komt. Aangezien de servers in Duitsland (waarschijnlijk? kan ook Helsinki zijn) staan, en we weten hoe streng ze in Duitsland de auteursrecht handhaven is het misschien niet heel slim, tenzij het misschien nog onder de Thuiskopieregeling valt. Ik ben er snel mee gestopt, want ik vond het een te groot risico.

Sowieso is het niet heel netjes om Plex te draaien bij een provider die dit expliciet verbiedt. Als ze erachter komen ben je sowieso je account kwijt. Dus ik hoop dat je niet teveel waarde hecht aan je servers bij Hetzner.

[Ebbez]

3raser schreef op donderdag 22 mei 2025 @ 14:54:
[...]

Sowieso is het niet heel netjes om Plex te draaien bij een provider die dit expliciet verbiedt. Als ze erachter komen ben je sowieso je account kwijt. Dus ik hoop dat je niet teveel waarde hecht aan je servers bij Hetzner.

Ik geloof dat Hetzner het niet expliciet verbiedt (wss wel impliciet met voorwaarden), maar dat het juist Plex is die het niet toestaat om via Hetzner IP-adressen media te streamen, omdat ze juridische problemen willen voorkomen.

[AW_Bos]

Ik heb momenteel al een poosje een VPS'je bij Contabo draaien voor wat Docker based dingetjes: Zoals een ZMQ-listener meer wat OV open-data, een Camo-proxy (waarom eigenlijk nog ) en een MariaDB instance.

Nu viel mij op dat MariaDB enkele malen was uitgevallen. Na even zoeken kwam de aan uit de mouw: De server was gereboot vanaf de Contabo-kant. De reden weet ik niet, maar als je Docker-containers draait: Zorg ervoor dat ze na een reboot weer vanzelf opgestart worden. Meesten doen dat altijd, maar anyway... wees er extra alert op.

[idef1x]

Heeft lijkt mij niets met Contabo te maken, maar meer met welke policy je de containers opstart...

[RobertMe]

idef1x schreef op dinsdag 10 juni 2025 @ 14:31:
Heeft lijkt mij niets met Contabo te maken, maar meer met welke policy je de containers opstart...

Dat Contabo servers (regelmatig) opnieuw zou opstarten is wel raar. En dat is iets dat ik niet heb gemerkt in de jaren dat ik er nu klant ben. Betekent uiteraard niet dat het niet gebeurt / zou kunnen gebeuren.

Maar kan mij ook niet zo snel indenken waarom ze uberhaupt (regelmatig) zouden rebooten. Het beheer doe je uiteraard zelf, dus het is niet dat ze rebooten voor updates in het OS zelf. En onderhoud aan de host/hypervisor zullen ze hopelijk toch een live migratie doen.

[AW_Bos]

Ik vind dit wel opmerkelijk met mijn Contabo Servertje:

code:

root@mijn_server:~# last -x reboot
reboot   system boot  5.4.0-216-generi Mon Jun 23 15:35   still running
reboot   system boot  5.4.0-216-generi Fri May 30 10:44   still running
reboot   system boot  5.4.0-171-generi Wed Apr 23 03:23   still running
reboot   system boot  5.4.0-171-generi Wed Mar 20 13:32   still running
reboot   system boot  5.4.0-105-generi Thu Dec 28 18:38 - 12:25 (82+17:47)
reboot   system boot  5.4.0-105-generi Thu Dec 28 16:40 - 18:37  (01:57)
reboot   system boot  5.4.0-105-generi Thu Dec 28 16:36 - 16:40  (00:03)

Kijk, drie dagen geleden dus opnieuw. Maar wel vreemd dat de hele VPS regelmatig opnieuw wordt opgestart? Die bovenste 'still running' vind ik op zijn minst wel wat opvallend en zorgelijk.

In ieder geval heb ik mijn Docker policies even verbeterd zodat ze na een reboot netjes opstarten. maar dat is bijzaak. De reboots zijn belangrijker.

[ Voor 15% gewijzigd door AW_Bos op 26-06-2025 16:04 ]

[jurroen]

AW_Bos schreef op donderdag 26 juni 2025 @ 15:57:
De reboots zijn belangrijker.

Ik zou je aanraden om even contact met support op te nemen. Het is soms een beetje een zooitje daar, maar de support is voor redelijk basic issues wel okay.

Je bent in ieder geval niet de eerste met dit probleem. In mijn geval heeft support het verhuisd naar een andere host en sindsdien geen issues meer (behalve traag, om de een of andere reden draait deze VPS op een first gen i7).

[HexaLogic]

AW_Bos schreef op donderdag 26 juni 2025 @ 15:57:
Kijk, drie dagen geleden dus opnieuw. Maar wel vreemd dat de hele VPS regelmatig opnieuw wordt opgestart? Die bovenste 'still running' vind ik op zijn minst wel wat opvallend en zorgelijk.

Misschien een issue met de host waar je VPS op draait? Je kunt ook een monitoring tool draaien om te checken of de VPS ook af en toe down gaat.
Maar wellicht kun je inderdaad even contact opnemen met de support.

[AW_Bos]

Inmiddels heb ik er geen last meer van, en gaan mijn docker containers netjes automatisch aan bij een reboot. Ook heb ik deze server nu meegenomen in mijn notifcatie op Pushover.

Maar ik merk momenteel, zonder dat ik iets gewijzigd heb, dat Gitea vrij traag reageert, met uitschieters tot 8 seconden laadtijd tot een timeout 'verify' melding van Gitea. Ik zie geen hoge load op mijn server, met met 'top' is ook niks vreemds te zien. Zou dit iets kunnen zijn op het VPS platform, en kan ik nog wat onderzoeken? Wel ga ik als ik wat meer tijd heb Gitea even updaten, maar kijken waar de traagheid vandaan komt kan geen kwaad. Iemand nog wat tips om te achterhalen of het probleem op het VPS-platform van Contabo zit?

[ Voor 8% gewijzigd door AW_Bos op 14-11-2025 11:43 ]

[AW_Bos]

Inmiddels is de boel weer lekker vlot en snel na 24 uur. Ik heb niks aangepast (enkel server en docker container gerestart, wat niet meteen hielp), dus ik vermoed dat er iets was op het VPS-platform.