
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.