Dieser Artikel wurde maschinell übersetzt.

Unterwegs

Einführung in IPsec VPNs auf Mobiltelefonen

Ramon Arjona

Diese Nachmittag, während ich unterwegs, erhielt ich eine e-Mail-Nachricht bei meinem Telefon. Die Nachricht musste eine Verknüpfung zu einem Dokument ich war beauftragt,--ein Dokument auf einer SharePoint-Website nur über Intranet des Unternehmens zu lesen. Dies war eine Bummer, da musste ich warten, bis ich konnte mein Laptop starten, legen Sie eigene Smartcard in den Smartcard-Leser, erhalten in einem Café eine Wi-Fi-Verbindung, Herstellen einer meinem Laptop mit dem Unternehmens-VPN Verbindung und anmelden, bevor das Dokument gelesen werden könnte.

Leben wäre viel einfacher, wenn nur das Telefon verwendet konnte für den Zugriff auf die SharePoint-Website. Natürlich müssten mein Telefon eine magische Möglichkeit sicher im Unternehmensnetzwerk herstellen und authentifizieren mich. Mit anderen Worten, wie mein Laptop benötigen mein Telefon die Möglichkeit zum start einer VPN-Verbindung zum Netzwerk. Viele kommerzielle Telefon-Modelle, einschließlich Windows-Telefone im Lieferumfang enthalten eines integrierten VPN-Clients. Aber es Mängel in den am häufigsten verfügbaren VPN-Clients, gibt da Sie auf Version 1 von einer Spezifikation namens Internetschlüsselaustausch (IKEv1) basieren. IKEv1 ist stabil Teil des IPsec-Frameworks und eignet sich hervorragend für verkabelten Geräten oder Geräten wie Laptops mit relativ großen Batterien, die nicht verschieben um viel. Es ist jedoch nicht ideal für Mobiltelefone.

Sicher, verwende ich eine drahtlose Verbindung auf meinem Laptop zum Wechseln aus meinem Büro in einem Konferenzraum und wieder ein. Ich möglicherweise von einer drahtlosen Verbindung zu einem drahtgebundenen wechseln und erwarten, dass kein Verlust der Konnektivität. Aber wir nicht verschieben um fast so viel mit einem Laptop wie wir mit einem Telefon. Ein Telefon Übertragung mit Ihnen über Datenverkehr und in von Gebäude, in und aus den servergespeicherten Zustand wechselt. Sofern Sie einem Mobilfunk-Modem verwenden, wurde bei der letzten Ihren Laptop Sie mitgeteilt, die es roaming wurde? Im Allgemeinen ändert ein Telefon dessen auf der Netzwerk-Anlage mit einer Häufigkeit und die Komplexität, die ein Laptop nicht kümmern. Guys, die über die IKEv1-Spezifikation vorstellen müssen nicht Mobiltelefon Szenarios entweder kümmern, da nicht in den späten 90er Jahren, wenn RFC 2409 geschrieben wurde, Smartphones nur auf dem Markt weit verbreitet waren. Seitdem hat die Verwendung von Mobiltelefonen skyrocketed, und die Bedeutung von dem Mobiltelefon die Bedeutung der anderen, größeren Computergeräte, wie die Arbeitsstation oder den Laptop Herangehensweise begonnen hat.

IKEv1 nicht gut geeignet zu einer hochgradig mobile Formatvorlage der Datenverarbeitung, da IKEv1 besitzt eine gute Möglichkeit, eine Host bewältigen, die dem Punkt der Netzwerk-Anlage in wenigen Sekunden mehrmals ändern können. Wenn IKEv2 entworfen wurde, wurde auch ein Satz Erweiterungen aufgerufen, das Protokoll Mobilität und mehrfache Vernetzung (MOBIKE) entworfen, an das Mobiltelefon Szenario angepasst. Mithilfe dieser Erweiterungen wird 2009a Mobiltelefon VPN weitaus mehr praktische. Verschiedene Produkte auf dem Markt unterstützt IKEv2 und MOBIKE, einschließlich Microsoft Systems Center Mobile Device Manager (SCMDM).

In diesem Artikel werde ich die Grundlagen der Technologie hinter IKEv2 und MOBIKE behandeln. Davon ausgegangen, dass Sie über Kenntnisse in der IPv4- und Netzwerk, einige Kenntnisse über Mobiltelefone und ein grundlegendes Verständnis von Kryptografie verfügen. In diesem Artikel wird nicht IPsec ausführlich behandelt und ist nicht, besprechen Sie andere Arten von VPN-Technologien wie SSL-basierte VPNs. Auch wird nicht IPv6 besprochen. IPSec- und IKE-IPv4-Erweiterungen sind, aber Sie sind in IPv6, damit einige der Dinge, die wir berühren werde auf Hier wird weiterhin angewendet werden auf einem IPv6-Netzwerk integrierten. IPv6 führt jedoch genügend Komplexität und neue Begriffe, dass Sie ausreichende ausführlich behandelt werden würde nicht.

Sagen Sie ‘ AH ’

Drei Protokolle bilden den Kern von IPsec: Authentication Header (AH), ESP (Encapsulating Security Payload) und IKE. Um IKE zu beheben, müssen zunächst AH und ESP besprechen.

AH stellt kurz gesagt, sicher, dass wir senden Pakete manipuliert sind nicht. Es schützt die Integrität der unsere Pakete. AH stellt auch sicher, dass die Pakete gesendet werden vom Händler Ansprüche an Sie gesendet haben. Es gewährleistet die Authentizität der unsere Pakete. AH bietet jedoch nicht, alle Maß Privatsphäre oder Verschlüsselung. Ein Angreifer Zugriff auf das Netzwerk erhält konnte weiterhin Pakete ausspionieren, die von AH geschützt sind und Ihren Inhalt zu extrahieren. Er nicht, würde allerdings sich als eines authentifizierten Parteien tarnen noch in der Lage unsere Pakete während der Übertragung zu ändern. AH wird im RFC 4302 definiert.

Beispielsweise wird Alice und Bob VPN-Verbindung zwischen sich selbst eingerichtet haben und schützen Ihre Pakete mit AH gewählt haben. Torsten selbst im Netzwerk fügt ein und beginnt Pakete abfangen. Torsten kann Alice und Bob die Unterhaltung zu rekonstruieren, da er kann den Inhalt der Ihre Pakete Siehe und erkennen, welche Art von Datenverkehr zwischen diesen übergeben wird. Jedoch, er kann keine Nachricht von Alice an Bob Fälschen, ohne die erste abgefangen, und er kann nicht Bobs Nachrichten an Alice, entweder ändern. Beide diese Dinge sind durch AH verhindert.

AH kann in Transportmodus oder Tunnelmodus verwendet werden. Im Transportmodus die Nutzlast eines Pakets ist geschützt, und Pakete direkt in eine Host zum anderen weitergeleitet werden. Im Tunnelmodus das gesamte Paket durch AH geschützt ist und eine Ende eine IPsec "Tunnel" Pakete weitergeleitet werdenzum anderen. Tunneling erfolgt über die Kapselung des ursprünglichen Pakets. Bei beiden Enden des Tunnels ist ein Sicherheitsgateway. Das Gateway, das Senden eines Pakets sorgt für die Kapseln des Pakets durch Hinzufügen eines "äußeren"IP-Header und die Adresse. Dieser äußere Adresse leitet das Paket an Sicherheitsgateway am anderen Ende des Tunnels. Das Gateway, das das Paket empfängt ist für die Verarbeitung des AH, um zu bestimmen, dass das Paket stammt aus einem gültige Absender und noch nicht manipuliert wurde, und dann das Paket an Ihr endgültiges Ziel routet verantwortlich.

Im Transportmodus wird ein AH das Paket direkt nach der IP-Header hinzugefügt. Der AH steht vor dem nächsten Protokoll Layer im Paket (z. B. UDP oder TCP) und auch vor anderen IPSec-Header im Paket, z. B. den ESP-Header. IP-Header, die vor den AH muss den Wert 51, verfügen, der ist die magische Zahl AH, die teilt die Anwendung verarbeitet das Paket, dass angezeigt wird als nächste ein AH ist von der IANA zugewiesen. Abbildung 1 zeigt die Form eines Pakets nach mit einem AH hinzugefügt.

Im Tunnelmodus ruft der AH nach neuen IP-Header hinzugefügt. Eingekapselte IP-Header wird als Teil der Nutzlast, zusammen mit allem anderen behandelt. Dies ist im Abbildung 2 dargestellt. Die ersten 8 Bits eines Pakets von AH geschützten Geben Sie die Protokoll-ID der Nutzlast, die nach der AH stammen. Dies teilt dem Empfänger, was nach der AH-Nutzlast erwartet. Beispielsweise ist das Protokoll der nächste Ebene TCP, wird die PROTOKOLLKENNUNG auf 6 festgelegt. Dieses Feld wird das Next Header bezeichnet. (Sie fragen sich vielleicht warum Sie Protokoll nicht konsistent mit anderen Headern in IPv4 Weise aufgerufen wird. Der Grund ist die Konsistenz und Kompatibilität mit IPv6. Glücklicherweise müssen Sie nicht wirklich wissen viel über IPv6, um die Funktionsweise AH im IPv4-Netzwerk zu verstehen, jedoch Wenn Sie wissen wurden, warum Sie Next Header aufgerufen wird, werden die deswegen.)

Als Nächstes kommt die 7-Bit-Länge des AH-Nutzlast. Da nur 7 Bits, ist die Nutzlast Größe auf 128 Byte beschränkt. Dann kommt eine lange Zeichenfolge von Nullen--2 Bytes, in der Tat. Diese 2 Bytes sind für zukünftige Verwendung reserviert entsprechend auf die RFC so bis, die zukünftige Verwendung definiert ist, haben wir 2 leere Bytes, die für die Umstellung nur zusammen sind.

Diese 2 Bytes folgt Sicherheitsparameterindex (Security Parameter Index, SPI). Dies ist eine 32-Bit-Zahl, mit der die IPsec Security Association (SA) zu bestimmen, der AH zugeordnet ist. Ich werde im Detail über Sicherheitszuordnungen sprechen, wenn IKEv2 erläutert. Diese Zahl eine 32-Bit-Sequenznummer, die bei jedem gesendeten Paket erhöht folgt und wird verwendet, um Wiederholungsangriffe zu verhindern.

Nach der Reihenfolge kommt Anzahl ICV (Integrity Check Wert). Der ICV wird an den Absender berechnet, indem eine hashing Funktion, wie z. B. SHA-2 Zuweisen der IP-Header, der AH und der Nutzlast. Der Empfänger überprüft, dass das Paket manipuliert noch nicht durch Anwenden der gleichen hashing-Funktion und bestätigt, dass der gleiche Hash erzeugt wird.

Ich haben ESP

Wie AH können ESP (Encapsulating Security PAYLOAD) Integrität und Authentifizierung bereitstellen. Im Gegensatz zu AH bietet jedoch ESP Authentifizierung und Integrität nur für die Nutzlast des Pakets, nicht für den Paketheader. ESP kann auch verwendet werden, um Datenvertraulichkeit durch Verschlüsselung die Paketnutzlast. Theoretisch können diese Features von ESP unabhängig aktiviert werden, daher ist es möglich, eine Verschlüsselung ohne Authentifizierung und Integrität haben oder Integrität und Authentifizierung ohne Verschlüsselung. In der Praxis vornehmen nicht jedoch vorgehen ohne die andere sehr viel Sinn. Beispielsweise tun nicht wissen, dass eine Nachricht vertraulich an mich gesendet wurde mir gute, wenn ich auch vollständig sicher werden können, wer ihn gesendet hat. ESP wird im RFC 4303 definiert.

ESP wie AH kann im Tunnelmodus oder Transportmodus aktiviert werden. Der ESP-Header muss nach der AH eingefügt werden. Im Transportmodus verschlüsselt ESP die Nutzlast des IP-Pakets. ESP im Tunnelmodus behandelt das gesamte eingekapselte Paket als Nutzlast und verschlüsselt ihn. Dies ist in Abbildung 3 dargestellt.

Der Verschlüsselungsalgorithmus wird durch einen Vorgang der Aushandlung zwischen den Peers ausgewählt, die die IPSec-SA einzurichten. Erweiterte Encryption Standard (AES) ist eine allgemeine Wahl des-Verschlüsselungsalgorithmus für moderne Implementierungen. Natürlich müssen AES verwenden, Sie zuerst einen gemeinsamen geheimen Schlüssel für zwei Hosts verfügen, die über eine sichere Kommunikation zu starten. Manuell die Host Zuweisen des gemeinsam genutzten Schlüssels ist ein unpraktisch Ansatz, da es nicht skaliert werden, aber Sie Schlüsselaustausch Diffie-Hellman-(DH) verwenden, können um den geheimen Schlüssel bereitstellen.

Diffie-Hellman-Gruppen

DH-ist ein Protokoll,, zwei Parteien ermöglicht um einen geheimen Schlüssel über einen unsicheren Kanal freizugeben, und ist für die Verhandlung, die in IKE-stattfindet. Der gemeinsame geheimen Schlüssel, der über DH mitgeteilt wird Verwendung möglich einen Kommunikationskanal erstellen, der sicher verschlüsselt ist. Berechnungen, die in DH wechselt ist komplex, und ich wird nicht in diese hier ausführlich wechseln. Wenn Sie mehr darüber erfahren interessiert sind, überprüfen Sie die Ressourcen, die modulare exponentielle (MODP)-Gruppen und Ihre Anwendungen mit DH abdecken. Für unsere Zwecke genügt es um zu sagen, dass eine DH-Gruppe eine bestimmte Sammlung von Zahlen mit einer mathematischen Beziehung und eine eindeutige Gruppe. ist

DH-Gruppe wird angegeben, wenn eine sichere Verbindung mit IPsec, während der IKE-Aushandlung eingerichtet wird. In diese Aushandlung müssen DH-Gruppe gefunden, die beide unterstützen die beiden Peers versuchen, eine sichere Verbindung herzustellen. DH-Gruppen mit höheren IDs haben höhere kryptografische Stärke. Beispielsweise zwischen 70 und 80 Bits die ersten DH-Gruppen, die in der ursprünglichen IKE-Spezifikation aufgerufen werden über die gleichen kryptografische Stärke als symmetrische Schlüssel mit hatte. Mit der Einführung von stärkere Verschlüsselungsalgorithmen wie z. B. AES war mehrere Stärke von DH-Gruppen zu verhindern, dass die DH-Gruppen eine schwache Glied in kryptografischen Kette erforderlich. Daher bieten neuere in RFC 3526 angegebene DH-Gruppen geschätzte Stärke zwischen 90 und 190 Bits.

Der Nachteil dieser neueren DH-Gruppen ist, dass Ihre größere Stärke bei Kosten stammt: mit den Gruppen stärkeren ist mehr Verarbeitungszeit erforderlich. Dies ist einer der Gründe, warum Peers eine sich gegenseitig akzeptabel DH-Gruppe handeln müssen. Beispielsweise Mein Telefon verfügen möglicherweise nicht genug Verarbeitungsleistung, für den Umgang mit DH-Gruppe 15, so dass er nur DH-Gruppe 2 unterstützen möchte. Während dem Versuch, Herstellen einer IPsec-Verbindung mit einem Server, der mein Telefon DH-Gruppe 2 vorschlagen wird, und wenn der Server DH-Gruppe 2 unterstützt, die Gruppe – verwendet werden selbst wenn der Server möglicherweise konnte haben eine stärkere DH-Gruppe verwendet. Natürlich, wenn die beiden Peers auf eine allgemeine DH-Gruppe können nicht, werden Sie kann nicht für die Kommunikation.

Das ist ausreichend Hintergrund. Sprechen wir über IKE.

Ich wie IKE (und so sollten Sie)

IKE ist zum Herstellen einer Verbindung IPSec-Peers verwendet. Diese Verbindung wird eine Security Association (SA) bezeichnet. Es gibt zwei Arten von Sicherheitszuordnungen, die IKE_SA und die CHILD_SA. Die IKE_SA wird zuerst festgelegt. Es ist, wobei der gemeinsame geheime Schlüssel über DH ausgehandelt wird und wo Verschlüsselungs- und Hashingalgorithmen auch ausgehandelt werden. Die CHILD_SA wird, in dem Netzwerkverkehr übertragen, AH, ESP oder beide geschützt.

Jede Anforderung in IKE erfordert eine Antwort, die wodurch es praktisch, hinsichtlich der Paare von Nachrichten zu denken ist. Die erste Nachricht Paar heißt IKE_SA_INIT und zum entscheiden, welche kryptografischen Algorithmus und DH die Peers Gruppe sollten verwenden. Da Kryptografie noch während dieses Austauschs bestimmt wird ist, ist dieses Nachrichtenpaar nicht verschlüsselt. Das nächste Paar der Nachrichten wird IKE_SA_AUTH aufgerufen. Dieser Austausch authentifiziert während IKE_SA_INT gesendeten Nachrichten und beweist die Identität der Initiator und Responder. Diese Schritt ist erforderlich, da die erste Nachricht, in Klartext gesendet wurde--müssen hergestellt einen sicheren Kanal, den Peers jetzt müssen miteinander Beweisen, dass Sie tatsächlich sind diese Identität sind und, dass Sie wirklich diese Unterhaltung starten sollen. Der IKE_SA_AUTH-Nachrichtenaustausch richtet auch die erste CHILD_SA, häufig nur CHILD_SA zwischen den Peers erstellt wird.

Ein CHILD_SA ist eine Verbindung simplex-- oder unidirektionale--, sodass CHILD_SAs immer paarweise, einrichten festgelegt sind. Wenn eine SICHERHEITSZUORDNUNG in einem Paar gelöscht wird, sollte der anderen gelöscht werden. Dies wird in IKE-durch informative Meldungen behandelt. Pro RFC 4306 enthält eine informative Nachricht 0 (null) oder mehr Nachrichten, Notification, löschen oder konfigurieren. Angenommen Sie haben wir ein Initiator, der einem PC und einer Antwort, die einen Server. Der PC beschließt, die CHILD_SA-Verbindung schließen und beenden das VPN. Sendet er eine informative Nachricht mit einer Nutzlast löschen, an den Server, der die SA zum Löschen durch seine SPI identifiziert. Der Server Löscht diese eingehende SICHERHEITSZUORDNUNG und sendet eine Antwort an den PC So löschen Sie die Hälfte der SICHERHEITSZUORDNUNG. Der Computer empfängt diese Meldung und löscht die Hälfte der SICHERHEITSZUORDNUNG und alles ist großartig.

Natürlich Dinge funktionieren möglicherweise nicht immer auf diese Weise. Ein Initiator oder Responder möglicherweise letztlich mit einer SICHERHEITSZUORDNUNG in einer "Hälfte geschlossen"Status, in denen ein Mitglied der SA-Paar geschlossen, aber die andere ist noch geöffnet. Die RFC gibt an, dass dies eine außergewöhnlichen Bedingung ist, aber es nicht für ein Peer um allein diese halb offene Verbindungen schließen zulassen. Stattdessen der Peer soll die IKE_SA löschen, wenn der Verbindungsstatus ausreichend--instabil, aber löschen die IKE_SA löscht Alf CHILD_SAs, die darunter erstellt wurden. Beiden Fällen wäre auf einem Telefon mühsam, da der CHILD_SA geöffnet halten knappen Systemressourcen beanspruchen, würde wie beenden und neu Erstellen des IKE_SA zu müssen.

Darüber hinaus ist es für eine Peer am Ende einer SICHERHEITSZUORDNUNG zu verschwinden vollständig, ohne dem System auf der anderen Seite der SICHERHEITSZUORDNUNG mitteilt, dass es gute ist möglich. Dies ist eine Situation, die besonders anfällig für Mobiltelefone auftreten. Sehen Sie sich beispielsweise ein Szenario, in dem ein Benutzer Mobiltelefon eine IPsec-VPN-Verbindung mit einem Server eingerichtet hat. Mobiltelefon-Benutzer wechselt in einem Keller und verliert Ihre Funksignal. Der Server hat keine Möglichkeit bekannt, dass das Telefon verschwunden in eine schwarze, damit weiterhin auf die CHILD_A Nachrichten senden, aber keine Antwort empfängt. Es wäre ebenso für das Telefon starten Senden von Nachrichten in ein schwarzes Loch aufgrund von Routingproblemen Mobilfunk Netzwerk möglich. Nichts könnte ein Peer Verfolgen eines anderen verloren gehen kann zu dieser Bedingung führen, die Kosten für das Telefon ist jedoch größer als die Kosten auf dem Server, da die Ressourcen auf dem Telefon mehr knapp sind.

Warum ist es ungültige unten löscht und die SICHERHEITSZUORDNUNG wiederherstellen?

Die kurze Antwort ist unten Zerreißen und Neuerstellen der SICHERHEITSZUORDNUNG wertvolle Ressourcen, die das Telefon zu verschwenden can’t verwendet. Insbesondere CPU in kryptografischen Berechnungen verbraucht ist, und während des Transceivers wird verwenden, senden und Empfangen von große Datenmengen, die Lebensdauer der Batterie Kosten. Die übertragenen auch große Datenmenge verbraucht Bandbreite, die Geld Kosten – insbesondere in platziert, wo Daten zu-/Abschlag durch die KB plant.

Da Senden einer Nachricht auf dem Radio Kosten Stromversorgung und Stromversorgung am Telefon begrenzt ist, muss das Telefon Situationen Black-Hole erkennen und behandeln Sie Systemressourcen sparen. Dies erfolgt normalerweise über einen Prozess deaktivierter Peer Erkennung (DPD), in dem ein Peer, der vermutet, dass es auf einen Black-Hole sprechen möglicherweise sendet eine Nachricht anspruchsvolle Nachweis für die Liveness aufgerufen. Wenn das Ziel dieser Anforderung nicht in einer geeigneten Zeitspanne antwortet, kann der Absender entsprechende Aktion zum Löschen der IKE_SA und die Ressourcen wird für ihn aufgewendete freizugeben dauern. Im Allgemeinen ist es vorzuziehen, um Nachrichten zu senden DPD nur, wenn es gibt kein Datenverkehr, die unterwegs über die SICHERHEITSZUORDNUNG und der Peer Grund hat zu vermuten, dass seine Partner auf dem die SICHERHEITSZUORDNUNG nicht mehr vorhanden ist. Zwar keine Anforderungen zum DPD auf diese Weise implementieren, Sinn nicht es viel ausführen, um Liveness von einem Peer zu bestätigen, die derzeit Sie andere Arten von Netzwerkverkehr Senden des.

Eine andere Situation, die bei VPN-Verbindungen Probleme verursachen kann ist eine Host ändern seiner IP-Adresse. Die IP-Adresse eine Host wird zum zusammen mit dem 32-Bit-SPI Erkennen eines bestimmten Host und eine SICHERHEITSZUORDNUNG zugeordnet. Wenn eine Host seine IP-Adresse verliert, ist auch diese Zuordnung verloren, und die SICHERHEITSZUORDNUNG muss unterbrochener nach unten und mit der neuen IP-Adresse neu erstellt werden.

Wie bereits erwähnt vor haben, ist dies nicht viel ein Problem mit Desktops oder Laptops. Ein PC möglicherweise verlieren eine DHCP-Lease und erhalten Sie eine neue IP-Adresse, aber die meisten DHCP-Serverimplementierungen machen es sehr wahrscheinlich, dass der Computer dieselbe IP-Adresse zugewiesen werden wird, der es vor dem hatte. Desktop-PCs ändern nicht mit anderen Worten, sehr häufig IP-Adressen. Laptops, lassen da Sie mobile, sind ändern Ihre Punkt des Netzwerk-Anlage und daher erhalten eine neue IP-Adresse erzwingen alle SA verfügen geöffnet, um zerstört und neu erstellt werden. Allerdings ist die Rate der Laptops IP-Adressen wechseln noch relativ selten, Vergleich mit die Rate mit der ein Telefon ist. Beispielsweise könnte ein Telefon, das die Möglichkeit, Daten über Wi-Fi und Mobilfunk Kanäle übertragen hat Netzwerken wechseln, jedes Mal ein Benutzer in oder aus Ihr Office-Gebäudes, durchläuft wie das Telefon von einem Wi-Fi erneut in eine GPRS-Verbindung und wieder zurück ändert. Im Gegensatz zu einem Laptop Bewegen in einem Bürogebäude, die auf derselben Verknüpfung Netzwerk bleiben und weiterhin daher eine topologically richtige Netzwerkadresse ohne eine Änderung möglicherweise hat das Telefon umgeschaltet, zwischen zwei grundlegend Netzwerken, ist es praktisch garantiert um IP-Adressen zu ändern. Dies führt zu einer unterbrochenen Verbindung auf dem Telefon Eintreten einer Übergabe zwischen Netzwerken. Das gleiche kann passieren, während das Telefon auf dem Mobiltelefon Netzwerk allein ist. Das Telefon möglicherweise roaming aktiviert und von dessen Heimnetzwerk zu einem fremden Netzwerk im Besitz eines anderen Mobilfunknetzbetreiber wechseln. Das Telefon möglicherweise von einem Bereich der Codeabdeckung auf einen anderen verschieben und an einen vollständig anderen Teil der Mobilfunkbetreiber Netzwerk angeschlossen werden.

Es gibt Anzahl aus anderen Gründen gesteuert, indem der Mobilfunkbetreiber, der eine unterbrochene Verbindung verursachen könnten. Diese häufigen Zerreißen nach unten und Neuerstellen der SICHERHEITSZUORDNUNG müssen das mobile VPN intractable, es nicht für die Erweiterungen zu IKEv2 MOBIKE genannt wurden.

MOBIKE

Das Protokoll IKEv2 MOBIKE ist in RFC 4555 definiert. Es ermöglicht Peers in ein VPN IPsec, um anzukündigen, dass Sie mehrere IP-Adressen haben. Eine dieser Adressen ist die SICHERHEITSZUORDNUNG für die Peer zugeordnet. Wenn der Peer erzwungen wird, um seine IP-Adresse wegen einer Änderung in der Netzwerk-Anlage zu wechseln, kann eine der zuvor identifizierten IP-Adressen oder eine neu zugewiesene Adresse in vertauscht werden ohne zu beenden und neu erstellen die SICHERHEITSZUORDNUNG.

Um die Fähigkeit, verwenden Sie MOBIKE anzugeben, enthält ein Peer eine Benachrichtigung MOBIKE_SUPPORTED in IKE_SA_AUTH Exchange. IKE_AUTH Exchange umfasst auch die zusätzlichen Adressen für den Initiator und der Antwortdienst. Der Initiator ist das Gerät, das die Einrichtung des VPN durch Senden der ersten IKE-Nachricht gestartet und ist verantwortlich für Entscheidungen über die IP-Adressen aus den verwenden ihm zur Verfügung, und die angeboten zu durch den Responder.

Wie die RFC weist darauf hin, ist der Initiator im Allgemeinen das mobile Gerät, da das mobile Gerät Weitere Bewusstsein von seiner Position im Netzwerk hat und daher besser ist für Entscheidungen über die Adressen zur Verwendung geeignet. Jedoch wird die RFC nicht angeben, wie diese Entscheidungen getroffen werden sollten. Im Allgemeinen ein Ende der IPsec-VPN-werden einem mobilen Gerät und das andere Ende einen Gatewayserver stationär Sicherheit werden. Die Spezifikation dieser Implementierung ist nicht erforderlich und lässt beiden Enden des Gateways verschieben – jedoch es nicht bieten eine Möglichkeit für die beiden Enden des Gateways gegenseitig wieder finden, wenn Sie zur gleichen Zeit verschieben. Wenn ein Peer seine Adresse aktualisiert und der anderen Peer dieselbe Funktion zur gleichen Zeit hat, es besteht keine Möglichkeit, diese Änderung mit entweder Peer zu kommunizieren und die VPN-Verbindung verloren.

Der Initiator verwendet der Responder Adressliste, um herauszufinden, das beste Adresspaar für die SICHERHEITSZUORDNUNG verwendet. Der Responder verwenden nicht der Initiator-Adressen, außer, als Mittel zur Kommunikation mit der Initiator, dass der Responder Adresse geändert wurde.

Wenn der Initiator sieht, dass Ihre Adresse geändert wurde, benachrichtigt er beispielsweise den Responder diese Tatsache mit eine informative Nachricht, die eine UPDATE_SA_ADDRESSES-Benachrichtigung enthält. Diese Nachricht enthält die neue Adresse, die auch in der Peer ESP Nachrichten startet verwendet wird. Der Empfänger der Update-Benachrichtigung zeichnet die neue Adresse und überprüft optional zurückgeben Routability, um sicherzustellen, dass die Adresse zu einem anderen mobilen Knoten gehört, wie gefordert wird. Folgende, startet der Responder unter Verwendung der neuen Adresse für den ausgehenden Datenverkehr mit ESP.

Natürlich kann der Initiator oder Responder nicht alle IP-Adressen bekannt, die es jemals für die Gültigkeitsdauer der SICHERHEITSZUORDNUNG verfügen wird. Ein Peer kann eine Änderung in der Liste der Adressen ankündigen, die es eine informative Nachricht unterstützt. Wenn der Peer nur eine Adresse verfügt, diese Adresse im Header vorhanden ist, und die Nachricht enthält die NO_ADDITIONAL_ADDRESSES-Benachrichtigung. Andernfalls wenn der Peer mehrere Adressen verfügt, wird eine dieser Adressen in der Kopfzeile der informative Nachricht abgelegt und die anderen in einer Benachrichtigung ADDITIONAL_IP4_ADDRESSES enthalten sind.

Diese Liste handelt es sich nicht um ein Update,--es ist die gesamte Liste der Adressen, die möchte, dass der Peer zu diesem Zeitpunkt ankündigen. Mit anderen Worten, wird die gesamte Liste jedes Mal, aber diese Kosten ist weiterhin niedriger als die Kosten für Zerreißen nach unten und Neuerstellen der SICHERHEITSZUORDNUNG jeder Änderung der Telefonnummer dem Punkt der Netzwerk-Anlage gesendet.

Zusammenfassung

Jetzt müsste eine grundlegende Vorstellung davon, wie ein IPsec-VPN mit MOBIKE mit einem Mobiltelefon funktionieren würde.

Die wachsende Verbreitung von Smartphones in der Homepage und Arbeitsbereich ist, stellen diese Lösungen wichtiger als Benutzer, beginnen eine Erfahrung gefordert wird, die mit auf Weitere Ressourcen Rich Computergeräte übereinstimmt. Personen sind für die Zeit wird Telefone, die mit dem Unternehmensnetzwerk verbinden können nicht akzeptieren, die nur einen Tag der Akkulebensdauer aufweisen und, leiden unter anderen Mängel der smart Telefonnummer, die wir alle mit vertraut sind. Dies wird nicht zuletzt. Wettbewerb und das erscheinen der bessere Hardware erzwingt die Übernahme von vollständigere, End-to-End-Lösungen, die Erfahrungen für das Telefon aktivieren, die auf Gleichwertigkeit mit dem Laptop und Desktop sind.

Und dann I, zusammen mit allen anderen, können Unternehmen SharePoint-Websites zu suchen, einfach indem Sie auf einen Link auf meinem Telefon.

Besonderer Dank an Melissa Johnson für Ihre Vorschläge und technischen Überprüfung dieses Artikels.

Ramon Arjona ist ein SDET Lead bei Microsoft.