Warum IKEv2 unter Android auf einem ungewöhnlichen UDP-Port scheitert

Ein natives IKEv2-Formular nimmt eine Adresse, keinen Port. Bestätigen Sie, dass der Client das unterstützt, setzen Sie beide Serverports und prüfen Sie dann Framing und Protokolle.

Das Gateway antwortet aus einem Grund auf UDP 4443 auf IKEv2, das Profil hat ein Feld namens Server, Sie tragen Hostname und Port ein, und das Telefon meldet, dass es den Server nicht erreicht oder die Adresse nicht auflösen kann. Nichts wird blockiert. Das native Android-Formular erwartet einen Host, und dasselbe gilt unter Windows. Ein eigener Port ist eine Client-Fähigkeit, bevor er eine Servereinstellung ist, und nur manche Clients lassen ihn ausdrücken. Arbeiten Sie die drei Teile der Reihe nach ab: was der Client sagen kann, worauf der Server lauscht und ob beide Seiten die Pakete gleich rahmen.

Was das Telefon tatsächlich gesendet hat

Eine Host-Port-Zeichenkette in einem Feld, das für einen Namen gedacht ist, wird als Name aufgelöst. Der Resolver liefert für vpn.example.net:4443 nichts zurück, und der Fehler, den Sie sehen, ist ein Namensauflösungs- oder Erreichbarkeitsfehler und keine Zeitüberschreitung auf einem Port. Diese Unterscheidung ist wichtig, denn ein neuer Versuch mit kürzerem Namen oder anderem Netz wird eine Zeichenkette nie reparieren, die das Formular nicht parsen kann.

Das native IKEv2-Profil unter Android ist wie der integrierte Windows-VPN-Client auf die standardmäßigen IKE-Ports festgelegt. Keines von beiden zeigt ein Portfeld, und keine Profilbearbeitung fügt eines hinzu. Wenn der Listener des Betreibers wirklich auf 4443 liegt, ist der integrierte Client das falsche Werkzeug und kein falsch konfiguriertes.

Verwenden Sie einen Client, der den Port zeigt

Der strongSwan-Client für Android dokumentiert einen konfigurierbaren Serverport in den erweiterten Profileinstellungen, deshalb taucht er in fast jedem funktionierenden Rezept für dieses Design auf. Diese Unterstützung gehört zu jenem Client: eine andere IKEv2-App oder ein Herstellerfork derselben App zeigt das gleiche Feld vielleicht nicht, obwohl der zugrunde liegende strongSwan-Daemon es unterstützt.

Bitten Sie den Betreiber um das ganze Set auf einmal: Gateway-Name, UDP-Port, Authentifizierungsmethode und die Serveridentität, die der Client erwarten muss. Ein eigener Port ist kein Grund, die Zertifikatsprüfung abzuschalten oder Protokolle zu wechseln. Tragen Sie den Port dort ein, wo der installierte Client ihn erwartet, und wenn dieser Client kein solches Feld hat, ist die Antwort ein anderer zugelassener Client und kein geratener Notbehelf.

Der Server hat zwei Ports, und beide müssen übereinstimmen

IKE beginnt auf UDP 500, und NAT-Traversal verschiebt IKE und gekapseltes ESP meist auf UDP 4500. Das sind in strongSwan getrennte Einstellungen, ein auf einen einzigen eigenen Port verschobener Server muss also beide auf denselben Wert ändern:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Bei einem Port für beide Rollen muss der Daemon IKE von ESP-in-UDP auf demselben Socket unterscheiden, was er über die Vier-Byte-Markierung tut, die kein ESP ist und einer IKE-Nachricht vorangeht. Deshalb kann ein Client nicht auf dem eigenen Port verhandeln und dann stillschweigend auf 4500 weitermachen, und deshalb verbirgt der Satz „einfach den Port ändern“ eine Anforderung an das Framing.

Eine Weiterleitung ist kein Listener

Die Weiterleitung von 4443 an einen gewöhnlichen IKE-Listener ist der Fehlermodus, der fast erfolgreich aussieht. Der erste Austausch kommt an, der Server antwortet, und dann stockt die Verbindung oder schlüsselt ins Nichts neu, weil die Antwort von einem anderen Port ausgeht und der spätere gekapselte Verkehr nie zum Zustand passt, den beide Enden aufgebaut haben. Eine Regel, die den Zielport umschreibt, ohne den Listener zu verschieben, erzeugt genau dieses halboffene Ergebnis.

Der Pfad muss außerdem UDP durchgehend erlauben. Dass TCP 443 durch ein Hotel- oder Mobilfunknetz kommt, sagt nichts über IKEv2 auf einem UDP-Port aus, selbst bei gleicher Nummer. Wo nur TCP 443 erlaubt ist, macht ein eigener UDP-Port aus IKEv2 kein HTTPS, und die richtige Antwort kann ein anderer Zugangsweg sein statt eines weiteren Portexperiments.

Trennen Sie die drei Stufen beim Testen

Zeichnen Sie auf dem Server auf, während der Client es einmal versucht. Eine Anfrage, die nie ankommt, ist eine Endpunkt- oder Firewall-Frage; eine Anfrage, die ohne Antwort ankommt, ist eine Listener- oder Richtlinienfrage; eine Antwort, auf die Stille folgt, ist die Framing- oder Identitätsfrage.

tcpdump -ni eth0 -vv udp port 4443

Lesen Sie dann die Meldung des Clients statt seines drehenden Indikators. Ein Vorschlagsfehler bedeutet, dass die Algorithmen nicht übereinstimmen, ein Authentifizierungsfehler bedeutet, dass Identitäten oder Zertifikate nicht übereinstimmen, und wiederholte Neusendungen ohne Antwort bedeuten, dass auf diesem Port nichts antwortet. Testen Sie jeweils eine Stufe und ändern Sie ein Feld zwischen den Versuchen; die strongSwan-Dokumentation zu NAT-Traversal beschreibt die Markierung und das Portverhalten, das Ihnen die Aufzeichnung zeigt.

Ähnliche Artikel