IPSEC IKEv2 versteckt HTTPS nicht

IPSEC IKEv2 versteckt HTTPS nicht

Ich verwende Linux strongSwan U5.3.5/K4.4.0-116-generic auf Ubuntu 16.04 mit IOS 11 IKEv2-Client.

Die Verbindung konnte auf meinem Client (IOS 11) erfolgreich hergestellt werden und wenn ich auf die IP-Check-Webseite gehe, z. B. myip.com, wird die Adresse des VPN-Servers angezeigt.

Ich habe jedoch festgestellt, dass eine Verbindung zu einem angepassten Port auf demselben Server für HTTPS von meiner Evil-NAT-Firewall blockiert werden kann, selbst wenn IKEv2 eingerichtet ist.

Nach meinem Verständnis erstellt IPSEC einen Tunnel über Port 500/4500 und verschlüsselt den gesamten Datenverkehr. Daher frage ich mich, wie meine Unternehmens- oder andere (nationale) Firewall zwischen unterschiedlichem Datenverkehr unterscheiden wird. Beispielsweise kann sie meine HTTPS-Anfrage auf einem beliebigen Port ablegen.

Ich habe versucht, direkt über die IP-Adresse darauf zuzugreifen, d. h.https://xx.xx.xx.xx:12345, aber es scheint keinen Unterschied zu machen.

Ich vermute, dass dieser Tunnel kein End-to-End-Tunnel (von meinem iPhone zum Server) ist. Da sich mein iPhone hinter NAT befindet, ist die Verbindung von meinem iOS zu meinem Firmen-Gateway irgendwie nicht verschlüsselt. Ist das der Grund?

Hier ist die ipsec.conf-Verbindung:

config setup
    cachecrls=yes
    uniqueids=yes
    charondebug=""

conn %default
    keyingtries=%forever
    dpddelay=30s
    dpdtimeout=120s


conn IKEv2-EAP-TLS
    auto=add
    type=tunnel
    keyexchange=ikev2
    dpdaction=clear
    dpddelay=300s
    authby=pubkey
    left=%SERVERIP%
    leftid=%SERVERIP%
    leftsubnet=0.0.0.0/0
    leftcert=vpnSrvCert.der
    leftsendcert=always
    right=%any
    rightid=%any
    rightsourceip=10.10.10.0/24
    rightdns=8.8.8.8,8.8.4.4
    rightauth=eap-tls

[Update] Nach einigem Herumprobieren glaube ich, dass der Grund das ist, was BillThor beschrieben hat. Ich habe festgestellt, dass in einer WLAN-Umgebung ohne Zensur, wenn ich mich mit dem HTTPS-Port auf demselben (IKEv2) Server1 verbinde, es sich um eine separate TCP-Verbindung handelt.

Als ich andererseits von einem zensierten WLAN aus eine Verbindung zu einem anderen L2TP-Server2 (nicht HTTPS) herstellte, konnte ich erfolgreich eine Verbindung zum HTTPS-Port des ursprünglichen Server1 herstellen.

Antwort1

VPN-Verkehr lässt sich leicht durch Paketprüfung oder in diesem Fall einfach durch die verwendeten Ports erkennen. Es ist durchaus möglich, dass Ihr Unternehmen weiß, was Sie versuchen oder tun.

Wenn Sie versuchen, dieselbe IP-Adresse zu erreichen, die Sie für die Verbindung zum VPN verwenden, wird diese nicht an das VPN gesendet. Zumindest ist dies die Adresse des VPN-Servers, mit dem eine direkte Verbindung hergestellt wird. Das VPN kann das Ziel möglicherweise für Ports weiterleiten, die vom VPN nicht verwendet werden.

Da sich Ihre rechte Seite im privaten Adressraum 10.0.0.0/8 befindet, wird Ihre IP-Adresse auf Ihrer Seite einer Netzwerkadressübersetzung unterzogen. Dies kann zu Störungen führen, wenn mehrere Geräte im selben LAN eine Verbindung zum selben Remote-VPN-Server herstellen.

Wenn Ihr Browser-Datenverkehr immer an das VPN weitergeleitet werden soll, müssen Sie Ihren Browser so konfigurieren, dass er einen Proxy-Server an einer über das VPN erreichbaren Adresse verwendet. Wenn Ihre Adresse als Ihre lokale IP-Adresse angezeigt wird, durchläuft sie das VPN.

verwandte Informationen