Zusammenfassung

  • RFC 4084 unterscheidet Web-, Client-, Firewall- und vollständige Konnektivität ohne ein Angebot moralisch abzuwerten. Entscheidend ist die Offenlegung der gelieferten und erlaubten Funktionen.
  • Ein belastbarer Fähigkeitsnachweis hält Werbung, Vertrag, Provider-Konfiguration und Beobachtung auseinander. Ein funktionierender Tunnel oder Relay ist kein Wartungsversprechen.

Die Abnahme prüft häufig das Falsche

Am Bereitstellungstag laden Webseiten und der Durchsatz stimmt. Später zeigt sich, dass ein Außenstandort keine eingehende Überwachungssitzung annehmen kann, ein VPN nach Leerlauf abbricht oder eine P2P-Anwendung nur über einen Relay funktioniert. Der Zugang ist nicht zwingend defekt. Die Abnahme hat lediglich Eigenschaften vorausgesetzt, die nie beschrieben wurden.

RFC 4084 wurde 2005 als BCP 104 veröffentlicht. Das Dokument ordnet Angebote in Web-Konnektivität, reine Client-Konnektivität ohne öffentliche Adresse, reine Client-Konnektivität mit öffentlicher Adresse, durch den Provider verwaltete Firewall-Konnektivität und vollständige Internet-Konnektivität. Diese Begriffe sind ausdrücklich nicht abwertend. Ein kleiner Funktionsumfang kann der passende sein. Die BCP verlangt keine bestimmte Produktstufe, sondern verständliche Information.

Damit wird die technische Diskussion sachlicher. Der Käufer muss nicht beweisen, dass ein Angebot „kein echtes Internet“ sei. Er muss festlegen, welche Funktionen sein Betrieb benötigt, und deren Status belegen.

Adresse, Erreichbarkeit und Erlaubnis

Eine öffentliche Adresse ist weder automatisch von außen erreichbar noch automatisch zum Serverbetrieb zugelassen. RFC 4084 beschreibt reine Client-Konnektivität mit öffentlicher Adresse, bei der VPN meist funktioniert, Server jedoch vertraglich oder durch Eingangsfilter untersagt sind. Private Adressen und NAT begrenzen typischerweise Server und viele P2P-Funktionen. Für den Begriff vollständige Konnektivität sind providerseitige NAT-, Proxy- und Portbeschränkungen unvereinbar.

Der Nachweis erfasst deshalb IPv4 und IPv6, exklusive oder geteilte Zuweisung, Stabilität, externe Kennzeichnung als dynamisch, Reverse DNS, Übersetzungspunkt, eingehende Reichweite und Kontrollinhaber. Eine auf Kundenwunsch gebuchte Firewall muss anders erscheinen als eine Standardbegrenzung des Anschlusses.

RFC 4787 trennt NAT-Mapping und NAT-Filterung. Die Lebensdauer des Zustands, seine Erneuerung und der entfernte Endpunkt beeinflussen das Ergebnis. Eine einmalige direkte Verbindung beweist nur einen konkreten Zustand. Sie sagt nichts über die nächste Stunde oder den nächsten Gegenstandspartner.

Workarounds bleiben wertvoll. Ein Relay, Rendezvous-Dienst oder Anwendungstunnel kann den Dienst retten. Daraus folgt jedoch weder eine Vertragszusage für eingehende Verbindungen noch ein Recht zum Serverbetrieb. RFC 4084 warnt genau vor der Verwechslung zwischen einem zufällig möglichen Umweg und der Absicht des Providers.

Vier getrennte Belegspuren

Beworben enthält Produktname, Version, öffentliche Beschreibung und Zeitpunkt. Vertraglich enthält Server- und P2P-Rechte, Adressstabilität, VPN, Mail, Filter, kundenseitige Sicherheitswahl und Supportpflicht.

Konfiguriert beschreibt die vom Provider kontrollierte Oberfläche: NAT, Eingangs- und Ausgangsfilter, Proxy, Interception, DNS, ICMP, Tunnel, Mailumleitung und kundenseitig angeforderte Regeln. Ohne Änderungskennung veraltet diese Information unbemerkt.

Beobachtet enthält interne und externe Messpunkte, Zeit, sichtbare Adressen, Protokoll, Port, Richtung, Leerlauf, Wiederholungen, Erfolg, Fehler und Unsicherheit. Diese Spur ändert keine Vertragsaussage und behauptet keine Ursache.

Zusätzliche Kennzeichen lauten vom Kunden angefordert, vom Workaround abhängig und erneut zu prüfen bei. Sie verhindern, dass eine Unternehmensrichtlinie dem Zugangsnetz zugerechnet wird oder eine Provider-Beschränkung hinter dem Wort Sicherheit verschwindet.

Mail zerlegt das pauschale Häkchen

RFC 4084 nennt providergebundene Submission-Server, gesperrte Ports zu fremden Mailservern, Umleitung, beschränkten POP3/IMAP4-Zugriff und dynamische Adresskennzeichnung. Dass Webmail läuft, belegt diese Wege nicht.

Die Matrix trennt authentifizierte Submission, externes SMTP, Remote-Abruf, Absenderdomäne, Reverse DNS, Reputation und Umleitung. Für VPN nennt sie Tunnelart, Richtung, Leerlauf und Fallback. Für DNS erfasst sie freie Resolverwahl oder Umleitung. Für ICMP nennt sie die verfügbaren Diagnosefunktionen. Bei eingehenden Diensten unterscheidet sie verboten, gefiltert, verändert und nicht geprüft.

Eine Beschränkung hat mehrere Rollen

RFC 7754 unterscheidet den Regelsetzer vom Durchsetzer. Ein Timeout oder Reset beweist allein weder Motiv noch Rechtsgrund noch Auftraggeber. Der Nachweis ordnet daher jede bestätigte Beschränkung dem anfordernden Akteur, dem ausführenden Akteur und dem technischen Punkt zu.

Eine enge Aussage ist belastbar: „Eingehendes TCP auf diesem Port scheiterte aus zwei unabhängigen Netzen; die Kundenfirewall enthält keine entsprechende Regel; der Vertrag nennt diese Provider-Grenze.“ Das ist für Support und Beschaffung nützlicher als eine pauschale Blockadebehauptung.

Quellen