So erreichen Sie einen privaten Dienst über ein VPN in einer virtuellen Maschine
Führen Sie beide Wege getrennt aus: das VPN des Gasts über NAT und ein Bein nur für den Host, das der Mac nutzt. Leiten Sie einen Port weiter, prüfen Sie ihn und schreiben Sie dann den Rückbau auf.
Behandeln Sie den Gast und den Mac als zwei getrennte Netze, die durch eine einzige schmale Tür verbunden sind. Die virtuelle Maschine behält ihren VPN-Client und ihren eigenen Weg ins Internet; der Mac erreicht genau einen Dienst über einen Adapter nur für den Host und einen einzelnen weitergeleiteten Port. Nichts anderes darf übertreten. Folgen Sie den Schritten der Reihe nach und halten Sie an, wenn einer scheitert, denn jeder spätere Schritt setzt voraus, dass die früheren gehalten haben.
Notieren Sie beide Wege, bevor Sie etwas ändern
Auf dem Gast zeigt ipconfig /all den Adapter, der den VPN-Transport trägt, und die Adresse, die er vom DHCP des virtuellen Netzes erhalten hat. Notieren Sie auf dem Mac die virtuelle Schnittstelle, die der Hypervisor für dieses Segment angelegt hat; bei VMware Fusion ist das Gerät nur für den Host normalerweise vmnet1, und Parallels vergibt einen eigenen Namen. Achten Sie darauf, wer dort Adressen verteilt, und schreiben Sie alles auf, denn das Subnetz nur für den Host wird häufig neu zugewiesen, wenn ein virtuelles Netz neu erstellt wird. Prüfen Sie den Netzwerkmodus der virtuellen Maschine im Hypervisor statt in Ihrer Erinnerung daran. Gemeinsamer Modus oder NAT-Modus für den internetzugewandten Adapter plus Modus nur für den Host für den dem Mac zugewandten Adapter ist die Anordnung, die diese Schritte voraussetzen.
Zwei Adapter, zwei Zwecke. Sie so zu vermischen, dass ein Adapter sowohl den Mac als auch das Internet bedient, macht aus einer schmalen Tür einen gerouteten Weg.
Bestätigen Sie zuerst das eigene VPN des Gasts
Starten Sie den Client innerhalb von Windows und bestätigen Sie, dass er beendet, mit welchem Test auch immer der Anbieter ihn dokumentiert. Gehen Sie nicht weiter, bis der Gast allein den privaten Dienst erreicht, denn ein Weiterleitungsproblem über einem defekten Tunnel hat zwei Ursachen und keine brauchbare Fehlermeldung. Notieren Sie die private Adresse, zu der der Dienst aus dem Gast heraus aufgelöst wird. Diese Adresse ist das Einzige, was die Weiterleitungsregel nennen sollte.
Schiebt der Client einen vollen Tunnel, trägt der Adapter nur für den Host weiterhin lokalen Verkehr, aber prüfen Sie, dass das private Ziel nicht so vom Tunnel erfasst wird, dass sich seine Adresse ändert. Ein Profil mit geteiltem Tunnel macht das einfacher und ist eine Anfrage an denjenigen wert, dem das VPN gehört.
Fügen Sie das Bein nur für den Host hinzu und testen Sie es allein
Stecken Sie einen Adapter nur für den Host an den Gast, geben Sie ihm eine statische Adresse in einem Subnetz, das sonst niemand nutzt, und bestätigen Sie, dass der Mac ihn anpingen kann. Testen Sie mit verbundenem und mit getrenntem VPN, denn die Adresse muss beides überstehen. Ein Gast, der nur antwortet, solange sein Tunnel steht, hat ein Routingproblem, das Sie noch nicht gefunden haben.
Windows kann den neuen Adapter als öffentliches Netz einstufen, was eingehenden Verkehr standardmäßig blockiert. Legen Sie das Profil fest, bevor Sie irgendetwas anderes debuggen.
Leiten Sie einen Port weiter, nicht das Subnetz
Bevorzugen Sie einen einzelnen weitergeleiteten Port gegenüber allgemeiner IP-Weiterleitung. Windows liefert netsh interface portproxy, das einen lauschenden Port an einen Zielhost und -port weiterleitet, und es braucht den laufenden Dienst IP Helper.
Setzen Sie listenaddress immer auf die Adresse nur für den Host. Lassen Sie es weg, werden alle Schnittstellen gebunden, was den Dienst jedem Netz aussetzt, in dem die virtuelle Maschine gerade sitzt. Fügen Sie eine Firewallregel hinzu, die auf die Schnittstelle nur für den Host und diesen einen Port beschränkt ist, damit Lauscher und Erlaubnis übereinstimmen. Eine proxybewusste Anwendung möchte stattdessen vielleicht einen kleinen Proxy im Gast, der die Verbindung beendet und keine Rückroute zum Mac braucht. Wählen Sie den Proxy, wenn das Protokoll es erlaubt, denn er scheitert konstruktionsbedingt geschlossen.
Prüfen Sie, dann schreiben Sie den Rückbau
Lösen Sie vom Mac aus den privaten Namen auf, führen Sie die beabsichtigte Operation aus, stoppen Sie dann das VPN des Gasts und bestätigen Sie, dass die Operation scheitert, statt stillschweigend zurückzufallen. Genau diese letzte Prüfung beweist, dass der Weg der ist, den Sie gebaut haben. Notieren Sie, welche Identität das Gateway sieht und wer die Weiterleitung nutzen darf.
Schreiben Sie den Rückbau als drei Schritte: den portproxy-Eintrag entfernen, die Firewallregel entfernen, den Adapter nur für den Host abziehen. Führen Sie ihn dann einmal aus, bevor Sie ihn brauchen, und bestätigen Sie, dass das eigene VPN des Gasts danach noch funktioniert. Verlangt Ihre Organisation, dass jeder Mac sich eigenständig registriert, halten Sie hier an und nutzen Sie stattdessen dieses Modell, denn ein gemeinsamer Weiterleitungspunkt bündelt den Zugriff auf einem Gast. Legen Sie die Adressen und den Port so oder so im Änderungsnachweis ab; die nächste Person will sie nicht neu entdecken.