CDN64: Dienste ohne Portfreigabe veröffentlichen – die Cloudflare-Alternative

CDN64 macht deine Webseite oder deinen Dienst über vier Edge-Server von IPv64.net in Deutschland aus dem Internet erreichbar – per IPv4 und IPv6, auch hinter DS-Lite und CGNAT und ohne Portfreigabe im Router. Hier steht, wie CDN64 funktioniert, welche Modi es gibt und wie du Namen, Zugriffslisten und Portmapper einrichtest.

Was ist CDN64 und wann brauchst du es?

CDN64 ist der Reverse-Proxy- und Tunnel-Dienst von IPv64.net. Besucher verbinden sich nicht mit deinem Anschluss, sondern mit den Edge-Servern von IPv64.net: srv07.cdn64.de und srv10.cdn64.de in Nürnberg sowie srv08.cdn64.de und srv09.cdn64.de in Falkenstein. Die Server reichen die Verbindung an deinen Dienst weiter – entweder durch einen Tunnel, den Node64 aus deinem Heimnetz aufbaut, oder direkt an ein öffentlich erreichbares Ziel. Ob die Server gerade online sind, zeigt die Server-Übersicht.

CDN64 hilft vor allem in diesen Fällen:

• DS-Lite oder CGNAT: Du hast keine eigene öffentliche IPv4-Adresse und kannst keinen Port freigeben. Mit dem Tunnel von Node64 erreichen Besucher deinen Dienst trotzdem – auch per IPv4.
• Keine Portfreigabe gewünscht: Der Tunnel wird von innen nach außen aufgebaut. Im Router bleibt jeder Port zu, deine eigene IP-Adresse bleibt verborgen.
• Nur IPv4 oder nur IPv6 am Anschluss: Die Edge-Server sind über beide Protokolle erreichbar.
• Schutz vor dem Anschluss: Zugriffslisten, Pause bei Angriffen, Grenzen je IP, WAF-Muster und die Erkennung von Angriffs-Werkzeugen wirken schon auf den Edge-Servern.

Im Heimnetz heißt der lokale Reverse-Proxy von Node64 PROXY64; CDN64 ist der Server-Teil bei IPv64.net. Verwaltet wird CDN64 auf ipv64.net/cdn64, in Node64 und über die CDN64-API. Ohne Anmeldung zeigt ipv64.net/cdn64 eine Übersicht mit den drei Modi.

So funktioniert CDN64

Ein Name, den du in CDN64 einschaltest (z. B. cloud.deinedomain.ipv64.net), zeigt im DNS auf seine Edge-Server – wie viele, legt die Kontoklasse fest (siehe Server je Name). Ein Besucher landet bei einem der Server. Der Server erkennt am Namen, wohin die Verbindung gehört, und reicht sie weiter.

 Besucher (IPv4/IPv6)
        │  DNS: A/AAAA der Edge-Server deines Kontos (TTL 10 s)
        ▼
 ┌──────────────────────┐     ┌──────────────────────┐
 │ Edge-Server          │     │ Edge-Server          │
 │ Nürnberg (2×)        │     │ Falkenstein (2×)     │
 └──────────▲───────────┘     └──────────▲───────────┘
            ║ Tunnel (Modus 1/2)         ║ Tunnel (Modus 1/2)
            ║ von Node64 aufgebaut       ║
 ┌──────────╨────────────────────────────╨───────────┐
 │ Node64 im Heimnetz – Router: kein Port offen      │
 └───────────────────────────────────────────────────┘
 Modus 3: Die Server verbinden sich direkt mit deinem
 öffentlich erreichbaren Server, ohne Tunnel.

Der Tunnel von Node64

In Modus 1 und 2 baut Node64 ausgehend zu jedem Edge-Server deines Kontos einen eigenen Tunnel auf (QUIC über UDP, Port 7844 oder 443; ist UDP gesperrt, TLS über TCP). Für deinen Router ist das eine normale ausgehende Verbindung. Jeder Tunnel meldet sich mit einem eigenen Token an. Technische Details – Ports, Rückfall auf TCP, Keepalive – erklärt die Node64-Doku unter CDN64 – Tunnel ohne Portfreigabe.

Load-Balancing und Ausfallsicherheit

• Mehrere Server per DNS: Das DNS nennt die Adressen der Edge-Server deines Kontos. Ab zwei Servern liegt einer in Nürnberg und einer in Falkenstein; Besucher verteilen sich automatisch auf sie.
• Server fällt aus: Meldet sich ein Edge-Server 45 Sekunden lang nicht bei IPv64.net und antwortet er auch nicht auf eine direkte Prüfung, nimmt IPv64.net seine Adressen aus dem DNS – solange ein anderer Server erreichbar ist. Bis dahin tragen die übrigen Server deines Kontos. Bleibt er länger als 3 Minuten weg (also nicht nur ein Neustart), springt für Konten, denen er zugeteilt ist, ein anderer Server ein, möglichst am selben Standort: Das DNS bekommt dessen Adressen, Node64 verbindet sich binnen einer Minute zusätzlich dorthin – ohne die Verbindungen zu den anderen Servern zu unterbrechen. Hat dein Konto nur einen Server (Free), ist der Name bis dahin nicht erreichbar. Ist der Server wieder 30 Sekunden da, gilt wieder die alte Zuteilung. Sichtbar ist ein Failover auf ipv64.net/cdn64 (gelbes Abzeichen „failover“ am Namen, Hinweis am Tunnel), in Node64 (Dashboard-Karte PROXY64 und Abzeichen „srv08 → srv09“ in der Spalte CDN64), im Log der Node und in den Ereignissen der Namen.
• Parallele Verbindungen: Je nach Kontoklasse baut Node64 zu jedem Server mehrere parallele Tunnel-Verbindungen auf (Business bis 2, Company bis 4, je Name wählbar; siehe Server je Name). Die Server geben neue Besucher an die am wenigsten belastete Verbindung.
• Mehrere Tunnel für einen Namen: Ein Name kann mehreren Tunneln (also mehreren Node64-Instanzen) zugeordnet sein. Die Reihenfolge ist die Priorität: Es bedient der erste Tunnel, der gerade verbunden ist. Das ist eine Ausfallreserve, keine Lastverteilung zwischen den Nodes. Festlegen lässt sich die Liste über die API (Feld tunnels).

Server je Name

Nicht jeder Name nutzt alle Edge-Server. Die Kontoklasse legt fest, wie viele es sind: Free 1, Home / Supporter 2, Business wählbar 1 oder 2, Company wählbar 1 bis alle (die Auswahl wächst mit der Zahl der Server; „alle“ schließt künftige Server ein). Dazu wählen Business (1–2) und Company (1–4) die Verbindungen je Server, z. B. 1 Server mit 1 Verbindung oder 3 Server mit je 2 Verbindungen. Free (1 Server, 1 Verbindung) und Supporter (2 Server, je 1 Verbindung) sind fest. Die Werte gelten je Name (in Node64 je Proxy-Host für alle seine Namen), z. B. Name A mit 1 Server und 1 Verbindung, Name B mit 4 Servern und je 4 Verbindungen; in Modus 3 nur die Anzahl der Server. Das DNS eines Namens nennt nur seine Server. Der Tunnel einer Node verbindet zu den Servern aller ihrer Namen, je Server mit dem Höchstwert der Verbindungen der Namen dort; die Namen teilen sich die Verbindungen eines Servers.

• Zuteilung: IPv64.net teilt die Server automatisch zu – je Standort zuerst einer, dann Server, die andere Namen derselben Node schon nutzen (weniger Verbindungen), sonst der mit den wenigsten Zuteilungen. Die Zuteilung bleibt fest, bis sich die Anzahl ändert. Welche Server ein Proxy-Host gerade nutzt, zeigt Node64 in seiner Zeile in der Spalte CDN64.
• Server und Verbindungen wählen (Business, Company): in Node64 unter PROXY64 → Proxy-Hosts in der Spalte CDN64 (Knopf mit der Zahl der Server in der Zeile des Proxy-Hosts) oder per API, je Name. Danach stellt IPv64.net das DNS des Namens um; Node64 verbindet sich binnen einer Minute zu den neuen Servern, die Verbindungen zu den bleibenden laufen weiter.
• Mehrere Tunnel für einen Namen: Alle Tunnel des Namens verbinden sich zu seinen Servern, damit eine Reserve einspringen kann.
• Klasse gewechselt: Die neue Anzahl gilt binnen weniger Minuten; bleiben Server übrig, behält der Name die zuerst zugeteilten.
• Alter DNS-Eintrag beim Besucher: Landet ein Besucher noch bei einem Server, den der Name nicht mehr nutzt, reicht dieser ihn an einen Server mit deinem Tunnel weiter.
• Lastausgleich (Notbremse): Liegt ein Edge-Server 15 Minuten durchgehend über 70 % seiner Kapazität und ein anderer unter 40 %, zieht IPv64.net einen Namen (Modus 1/2) mit spürbarem Verkehr dorthin um – höchstens einen je Viertelstunde, nie während eines Server-Ausfalls und nie bei Company mit „alle“. Der neue Server kommt zuerst dazu; der alte fällt erst weg, wenn dein Tunnel auf dem neuen steht, es gibt also keinen Ausfall. Ein umgezogener Name bleibt danach 24 Stunden auf seinen Servern. Sichtbar ist der Umzug in den Ereignissen der Namen („Lastausgleich: srv08 → srv10“) und im Log von Node64.

Die drei Modi

Der Modus legt fest, wo die Verschlüsselung (TLS) endet und wie die Edge-Server dein Ziel erreichen.

Modus 1: durchreichen (Ende-zu-Ende)

Die Edge-Server lesen nur den Namen aus dem Verbindungsaufbau (SNI, bei HTTP auf Port 80 den Host-Kopf) und reichen die Verbindung unentschlüsselt durch den Tunnel an Node64. TLS endet erst in deiner Node, Zertifikat und Schlüssel bleiben bei dir. Inhalte, Pfade und Cookies sehen die Server bei HTTPS nicht. HTTP/3 (QUIC) reichen sie ebenfalls roh durch. Das ist der Standard und für fast alle Fälle die richtige Wahl.

Modus 2: TLS auf den Edge-Servern beenden

Die Edge-Server beenden TLS selbst (HTTP/1.1, HTTP/2 und HTTP/3) und schicken jede Anfrage mit der echten Besucher-IP durch den Tunnel an Node64. So können sie schon vor deinem Anschluss aussortieren: Grenzen für Anfragen je IP (darüber 429) und die Prüfung, ob der Host-Kopf zum SNI passt (sonst 421). Port 80 leitet mit 301 auf HTTPS um. Das Zertifikat holen die Server selbst (siehe Zertifikate); bis es da ist, reichen sie wie in Modus 1 durch.

Modus 3: direkt zum Ziel, ohne Node64

In Modus 3 gibt es keinen Tunnel. Die Edge-Server verbinden sich direkt mit deinem Ziel – wie ein klassischer Reverse Proxy. Das Ziel muss öffentlich erreichbar sein. Du richtest Modus 3 auf ipv64.net/cdn64 oder per API ein:

• Ziel: entweder die aktuellen A/AAAA-Records des Namens (dein DynDNS-Updater hält sie weiter aktuell, siehe DNS) oder ein festes Ziel – eine öffentliche IP-Adresse oder ein Hostname. Private, CGNAT-, Dokumentations- und andere nicht öffentliche Adressen sind nicht erlaubt.
• Backend: HTTPS (Standard, Port 443) oder HTTP (Port 80), Port frei wählbar. Optional prüfen die Server das Zertifikat des Ziels („Verify the target's certificate“, Standard aus). „Prefer IPv6“ (Standard an) verbindet zuerst per IPv6.
• Frontend: Stufe 0 = keine Webseite, nur Portmapper; Stufe 1 = nur HTTP (Port 80); Stufe 2 = HTTPS, Port 80 leitet auf HTTPS um (Standard); Stufe 3 = nur HTTPS (Port 443).
• Cache: Optional speichern die Server Antworten zwischen – bis zur Cache-Größe deiner Kontoklasse je Name. Gespeichert wird nur, was das Ziel selbst als cachebar markiert (Cache-Control: max-age/s-maxage oder Expires, ohne private, no-store, no-cache und ohne Set-Cookie), nur GET/HEAD ohne Anmeldung und höchstens 8 MB je Objekt. Der Antwort-Kopf X-Proxy-Cache zeigt HIT oder MISS.
• Weitere Eigenschaften: WebSockets funktionieren automatisch. Die IP des Besuchers kommt im Kopf X-Forwarded-For bzw. X-Real-IP an. Text-Antworten komprimieren die Server selbst, wenn das Ziel es nicht tut.

Zwischen Modus 1 und 2 kannst du jederzeit wechseln, das DNS bleibt gleich. Zwischen Modus 3 und den Tunnel-Modi geht das nicht direkt: Schalte den Namen aus und mit dem anderen Modus wieder ein.

Welcher Modus passt?

• Modus 1, wenn du Node64 nutzt und maximale Vertraulichkeit willst – dein Zertifikat, deine Regeln.
• Modus 2, wenn unerwünschter Verkehr schon vor deinem Anschluss gebremst werden soll (z. B. bei kleinem Upload) oder die Edge-Server das Zertifikat übernehmen sollen.
• Modus 3, wenn dein Server schon öffentlich erreichbar ist und du einen Reverse Proxy mit Cache davor willst – ohne Node64.

Was IPv64.net in Modus 1 und 2 jeweils sieht, vergleicht die Node64-Doku unter Was sieht ipv64?.

Voraussetzungen und Namen hinzufügen

Voraussetzungen

• Eine Kontoklasse mit CDN-Domains. Ohne CDN-Domains in der Klasse lehnt IPv64.net das Anlegen ab (siehe Kontingent).
• Der Name liegt in einer Domain deines Kontos – einer DynDNS-Domain oder einer eigenen Domain, die du bei IPv64.net verwaltest. Erlaubt sind die Domain selbst und jeder Name darunter, z. B. deinedomain.ipv64.net oder www.deinedomain.ipv64.net. Deaktivierte Domains zählen nicht.
• Auf dem Namen liegt kein CNAME und kein aktives DNS Failover.
• Für Modus 1 und 2: Node64 mit dem Modul PROXY64, verbunden mit deinem IPv64.net-Konto (siehe Node64 verknüpfen). Ausgehend muss UDP oder TCP auf Port 7844 oder 443 erlaubt sein.
• Für Modus 3: ein öffentlich erreichbares Ziel (öffentliche IP-Adresse oder Hostname). Nutzt du die A/AAAA-Records des Namens als Ziel, muss mindestens einer davon eine öffentliche Adresse enthalten.

Modus 1 und 2 in Node64 einschalten

1. Proxy-Host anlegen
   In Node64 unter PROXY64 → Proxy-Hosts einen Host für den Namen anlegen, der auf deinen Dienst im Heimnetz zeigt.
2. CDN64 einschalten
   In der Spalte CDN64 auf Einschalten klicken und Modus 1 oder 2 wählen. Node64 meldet den Tunnel bei IPv64.net an, baut ihn auf und schaltet jeden Namen des Hosts ein.
3. Selbsttest abwarten
   Node64 prüft jeden Namen über alle Server deines Kontos und beide Adressfamilien. Danach ist der Dienst über CDN64 erreichbar.

Die Schritte im Detail stehen unter Einrichtung mit einem Klick in der Node64-Doku. Auf ipv64.net/cdn64 erscheinen diese Namen mit dem Hinweis Node64: Ziel, Modus, Zertifikat und Zugriffslisten verwaltest du in Node64; im Portal kannst du sie pausieren und ausschalten.

Modus 3 auf ipv64.net/cdn64 einschalten

1. Seite öffnen
   Auf ipv64.net/cdn64 die Karte Add a name (mode 3, direct to target) suchen.
2. Name eintragen
   Unter Name eine Domain deines Kontos oder einen Namen darunter eintragen.
3. Ziel festlegen
   Unter Target die A/AAAA-Records des Namens oder ein festes Ziel wählen, dazu Backend (HTTPS/HTTP), Port, Frontend-Stufe und auf Wunsch Cache.
4. Einschalten
   Mit Switch on stellt IPv64.net das DNS um. Die Server holen ein Zertifikat (etwa eine Minute), dann ist der Name per HTTPS erreichbar.

Über das Stift-Symbol in der Liste Names in CDN64 änderst du später Ziel, Zugriffsliste und Portmapper. Alle Einstellungen gibt es auch per API.

Ausschalten

Mit dem Ein/Aus-Symbol (Switch off) auf ipv64.net/cdn64, mit Ausschalten in Node64 oder per API schaltest du einen Namen aus. Das DNS zeigt dann wieder auf deine bisherigen Adressen; Ziel, Zugriffsliste, Portmapper und Zertifikat des Namens werden entfernt. Schaltest du einen Namen in Modus 1 oder 2 im Portal aus, übernimmt Node64 das. Wer den Dienst nur kurz sperren will, ohne seine Adresse preiszugeben, nimmt besser die Pause.

Verwaiste Tunnel: Node64 gelöscht, ohne abzumelden

Löschst du einen Node64-Container, ohne die Namen vorher auszuschalten, bleibt sein Tunnel bei IPv64.net verwaist (nur Modus 1 und 2). Dann gilt:

• Ab 48 Stunden ohne Verbindung zeigt ipv64.net/cdn64 einen Hinweis mit dem Datum, an dem aufgeräumt wird. Eine E-Mail oder Benachrichtigung gibt es nicht.
• Nach 14 Tagen ohne Verbindung (ein nie verbundener Tunnel zählt ab dem Anlegen) entfernt IPv64.net den Tunnel samt Token und seine Namen: Das DNS kommt auf deine ursprünglichen Records zurück, Ziel, Zugriffsliste, Portmapper und Zertifikat der Namen werden gelöscht. Das steht im Konto-Log.
• Ein Name, der zusätzlich an einem anderen Tunnel hängt, bleibt; nur die Zuordnung zum verwaisten Tunnel fällt weg.
• Meldet sich die Node selbst noch bei IPv64.net (z. B. ist nur PROXY64 ausgeschaltet), bleibt der Tunnel stehen.
• Aufgeräumt wird nur, wenn gerade ein Edge-Server erreichbar ist und in den letzten 15 Minuten irgendein Tunnel verbunden war. Eine Störung bei IPv64.net führt so nicht zum Löschen.

DNS und Zertifikate

Beim Einschalten stellt IPv64.net das DNS selbst um – du musst keinen CNAME und keinen Record eintragen:

• Alle aktiven A- und AAAA-Records des Namens werden deaktiviert. Sie bleiben gespeichert und erscheinen in der Domain als „CDN64 Active“.
• Für jeden Edge-Server deines Kontos kommt ein A- und ein AAAA-Record mit TTL 10 Sekunden dazu. Diese Records verwaltet CDN64; du kannst sie weder bearbeiten noch löschen, auch nicht per API.
• Beim Ausschalten werden die Server-Records gelöscht und deine ursprünglichen Records wieder aktiviert.
• Beim Pausieren bleibt das DNS auf den Edge-Servern.
• Löschst du die Domain oder dein Konto, entfernt IPv64.net auch die CDN64-Namen darin; die Edge-Server lassen sie beim nächsten Abruf ihrer Konfiguration fallen.

DynDNS-Updates laufen weiter

Der DynDNS-Updater aktualisiert die deaktivierten Records weiter im Hintergrund. In Modus 3 mit dem Ziel „A/AAAA-Records des Namens“ nutzen die Edge-Server so immer deine aktuelle Adresse. Hat der Name für eine Adressfamilie keinen eigenen Record, sondern nur den Record des Edge-Servers, lässt der Updater ihn unverändert und meldet für diese Familie "cdn" (siehe Antworten).

Zertifikate

• Modus 1: Das Zertifikat liegt in deiner Node (Zertifikatsverwaltung von Node64). Die Edge-Server sehen es nie.
• Modus 2 und 3: Die Edge-Server holen das Zertifikat selbst bei Let's Encrypt – für den Namen und *.Name per DNS-01. Den TXT-Record _acme-challenge setzt IPv64.net dafür kurz in deiner Domain. Scheitert DNS-01, gibt es per HTTP-01 ein Zertifikat nur für den Namen. Ist Let's Encrypt an seiner Grenze, weichen die Server auf ZeroSSL aus.
• Ein Server bestellt, der andere übernimmt das Zertifikat. Zertifikat und Schlüssel liegen verschlüsselt bei IPv64.net; den Schlüssel dafür haben nur die Edge-Server.
• Erneuert wird 30 Tage vor Ablauf.

Schutz: Zugriffslisten, Ländersperre, Blocklisten, WAF und Pause

Ein Name in CDN64 ist in zwei Schichten geschützt: grob auf den Edge-Servern, bevor Verkehr deinen Anschluss erreicht, und fein in Node64 (Modus 1 und 2) mit der echten Besucher-IP.

Zugriffsliste (Allow / block list)

Je Name gibt es auf den Edge-Servern eine Liste mit IP-Adressen und Netzen (IPv4 und IPv6, z. B. 192.0.2.10 oder 2001:db8:1234::/48), höchstens 200 Einträge. Die Einstellung Default legt fest, was sie bedeutet:

Die Liste gilt für Webzugriffe und für die Portmapper des Namens. Ändert sich die Liste, trennen die Server auch schon offene Verbindungen. Auf ipv64.net/cdn64 bearbeitest du sie bei Namen in Modus 3; für Namen in Modus 1 und 2 geht das per API, sonst nutzt du dort die Zugriffslisten von PROXY64 in Node64.

Sperrliste aus Node64: Ab PROXY64 1.45 gelten die Sperrliste und die Freigabeliste unter PROXY64 → Zugriffslisten auch auf den Edge-Servern. Node64 schickt beide Listen für ihren Tunnel an IPv64.net, je Liste die ersten 1000 Einträge. Die Server weisen diese Adressen dann für alle Namen des Tunnels in Modus 1 und 2 schon beim Verbindungsaufbau ab, auch an den Portmappern. Die Freigabeliste geht vor. In der Statistik zählen diese Abweisungen als Zugriffsliste.

Ländersperre

Die Ländersperre („diese Länder sperren“ oder „nur diese Länder zulassen“) stellst du in Node64 je Proxy-Host und je Stream ein. Sie wirkt in Modus 1 und 2, weil Node64 die echte Besucher-IP bekommt. Die Länderlisten kommen täglich von IPv64.net. Details: Ländersperre in PROXY64. Auf den Edge-Servern selbst gibt es keine Ländersperre; in Modus 3 schränkst du den Zugang mit der Zugriffsliste ein.

Blocklisten

• Auf den Edge-Servern gilt für alle Namen und Modi eine feste Blockliste (Spamhaus DROP, alle 30 Minuten aktualisiert). Geprüft wird beim Verbindungsaufbau.
• In Node64 wählst du unter PROXY64 → Zugriffslisten selbst, welche IPv64-Blocklisten greifen – etwa die Gesamtliste, die v64 Blocklist aus dem Honeypot-Netz oder Listen von Cloud-Netzen. Die Auswahl kommt direkt von IPv64.net. Details: ipv64-Blocklisten in PROXY64.

Grenzen auf den Edge-Servern

Für alle Namen gelten auf den Edge-Servern Grenzen je IP (IPv6 je /64): höchstens 256 gleichzeitige Verbindungen und 50 neue Verbindungen pro Sekunde. In Modus 2 kommen Grenzen für Anfragen je IP dazu (darüber Antwort 429). Ab 80 % Auslastung eines Servers teilt er die Bandbreite gerecht auf; getrennt wird dabei niemand, nur gebremst. Die genauen Werte stehen unter Schutz vor Überlastung auf den Servern.

WAF-Muster und Angriffs-Werkzeuge (JA4)

Zwei weitere Filter auf den Edge-Servern halten automatisierte Angriffe und Scanner von deinem Anschluss fern:

• Angriffs-Werkzeuge (JA4) – alle Modi: Aus dem Verbindungsaufbau entsteht ein JA4-Fingerabdruck des Programms, ohne dass etwas entschlüsselt wird. Gehört er zu einem bekannten Angriffs-Werkzeug aus dem Honeypot-Netz von IPv64.net, schließen die Server die Verbindung. Auf die Liste kommt ein JA4 erst, wenn ihn mindestens drei unabhängige Accounts gemeldet haben; Browser (Chrome und alle Chromium-Browser, Firefox, Safari) stehen nie darauf. Stufen: aus, nur zählen oder sperren.
• WAF-Muster – Modus 2 und 3, Standard an: Abrufe wie .env, .git, wp-config.php oder ../ und typische Scanner wie sqlmap oder nikto bekommen 403. In Modus 1 sehen die Server die Anfragen nicht.

Geschaltet wird je Host in Node64: unter PROXY64 → Proxy-Hosts mit dem Schild-Knopf neben der Pause, nicht auf ipv64.net/cdn64 (per API mit PATCH). Welche Muster genau greifen und was die leichte WAF nicht kann, steht unter Schutz auf den Servern.

Schutz-Kennzahlen auf ipv64.net/cdn64

Unten rechts, unter den Node64-Tunneln, fassen vier kleine Kacheln die letzten 30 Tage aller Namen zusammen – auch, wenn du nur Modus 3 nutzt: beantwortete Anfragen samt ausgeliefertem Traffic, vor deinem Server abgewehrte Anfragen (Blocklisten, WAF, Überlast), gestoppte Angriffs-Werkzeuge (JA4) und der Anteil der Besucher, die über IPv4 kamen.

Unter jedem Namen zeigt ipv64.net/cdn64 neben dem Schild-Symbol, was die Edge-Server in den letzten 30 Tagen für ihn getan haben:

• blocked – abgewiesen, bevor etwas deinen Dienst erreicht hat: Blocklisten, Zugriffsliste, Überlast, WAF-Muster und Angriffs-Werkzeuge (JA4) zusammen
• IPs – gesperrte IP-Adressen (IPv6 je /64)
• overload – gestoppte Überlast durch die Grenzen für Verbindungen und Anfragen
• hidden – Verbindungen über CDN64, bei denen deine eigene Adresse verborgen blieb; in Klammern, wie viele davon über IPv4 kamen

Die Zahlen je Tag und Grund und die häufigsten Angriffs-Werkzeuge zeigt Node64 unter PROXY64 → CDN64 Statistik (mehr dazu), per API GET /cdn64o/protection.

Pause: die Notbremse

Mit Pause (Pause-Symbol auf ipv64.net/cdn64, Pausieren in Node64 oder per API) nehmen die Edge-Server für einen Namen sofort nichts mehr an – in allen Modi. Gedacht ist das als schneller Selbstschutz, etwa bei einem Angriff.

• Offene Verbindungen trennen die Server innerhalb weniger Sekunden, auch Portmapper, WebSockets und lange Downloads.
• Das DNS zeigt weiter auf die Edge-Server – deine eigene Adresse bleibt verborgen. Das ist der Unterschied zum Ausschalten.
• Einstellungen und Statistik bleiben erhalten. Fortsetzen geht mit demselben Knopf (Play-Symbol).
• Du kannst auf ipv64.net/cdn64 jeden Namen deines Kontos pausieren – auch Namen in Modus 1 und 2, wenn die Node selbst nicht erreichbar ist.

Portmapper: TCP und UDP über CDN64

Der Portmapper reicht rohe TCP- oder UDP-Verbindungen weiter – für Dienste ohne HTTP(S), etwa SSH, WireGuard, Spiele-Server oder die Proxmox-Oberfläche. Er öffnet auf allen Edge-Servern denselben Port zwischen 50000 und 62000. Erreichbar ist der Dienst dann als name:port, z. B. home.deinedomain.ipv64.net:55349.

• Portvergabe: Ist der Port deines Ziels im Bereich frei, bekommst du denselben. Sonst vergibt IPv64.net einen freien Port aus dem Bereich. Per API kannst du einen Wunschport angeben.
• Modus 1 und 2: Du richtest den Portmapper in Node64 am Stream ein (PROXY64 → Streams, „Über CDN64 aus dem Internet erreichbar“). Die Verbindung läuft durch den Tunnel, zu Hause ist kein Port offen. Siehe Portmapper in der Node64-Doku.
• Modus 3: Auf ipv64.net/cdn64 beim Namen unter Port mappings (TCP/UDP): Dienstname, Port deines Ziels und TCP oder UDP eintragen, Add. Die Server verbinden sich direkt zum Ziel; es sieht die Adresse der Server, nicht die des Besuchers. Mit Frontend-Stufe 0 nutzt ein Name nur den Portmapper, ohne Webseite.
• Für alle Modi: Zugriffsliste und Pause des Namens gelten auch für seine Ports. Der Traffic zählt zum CDN-Kontingent. Die Zahl der Portmapper hängt von deiner Kontoklasse ab.
• Leerlauf: TCP-Verbindungen ohne Daten in beide Richtungen trennen die Server nach 1 Stunde, UDP-Sitzungen nach 2 Minuten ohne Pakete.
• UDP: Als Schutz vor Reflexion darf das Ziel einem Besucher nur ein Vielfaches dessen schicken, was von ihm kam. Reine Einweg-Datenströme über UDP eignen sich daher nicht.

Kontingent und Traffic je Kontoklasse

Jeder eingeschaltete Name zählt als eine CDN-Domain. Der Datenverkehr (ein + aus, alle Server und Portmapper) zählt gegen den CDN-Traffic des Monats. Namen und Portmapper im früheren IPv64-CDN werden mitgezählt.

Die Werte stehen live unter Pricing und unter Konto & Limits; per API liefert sie GET /api/v2/plans. Deinen Stand zeigt ipv64.net/cdn64 oben in der Zeile Quota.

• Traffic aufgebraucht: Ist der Traffic des Monats erreicht, sperrt IPv64.net alle Namen des Kontos (Status blocked, Grund traffic); die Edge-Server weisen dann ab. Im neuen Monat gibt IPv64.net sie wieder frei.
• Upgrade: Nach einem Upgrade der Kontoklasse sind wegen Traffic gesperrte Namen sofort wieder frei; die Server übernehmen das nach etwa 10 Sekunden.
• Zählung: Die Edge-Server melden Traffic, Verbindungen, Anfragen und Abweisungen je Name regelmäßig an IPv64.net. Die Zahlen des Monats stehen in der Liste auf ipv64.net/cdn64 und in Node64.

Grenzen

• Nur Domains deines IPv64.net-Kontos. Namen in Domains bei anderen DNS-Anbietern lassen sich nicht einschalten.
• Kein CNAME und kein aktives DNS Failover auf dem Namen. Umgekehrt bietet DNS Failover die Records eines Namens in CDN64 nicht zur Auswahl an.
• Keine Platzhalter-Namen (*.) beim Einschalten. Ist für die Domain Wildcard eingeschaltet, nehmen die Edge-Server auch Unternamen des Namens an.
• Höchstens 10 Tunnel je Konto.
• Kein Cache in Modus 1 und 2 – dort cacht und komprimiert deine Node.
• Streams nur über den Portmapper: TCP/UDP-Dienste laufen über einen Port zwischen 50000 und 62000, nicht über 443.
• Dein Upload ist die Grenze: In Modus 1 und 2 hängt der Durchsatz am Upload deines Anschlusses.

Fehlersuche

Den Verlauf eines Namens – Einschalten, Änderungen, Pausen, Sperren, Ausfälle eines Edge-Servers – liefert die API unter GET /cdn64o/hosts/{id}/events. Weitere Hilfe gibt es in den FAQ und im v64.tech-Forum.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-11-04