Wir veröffentlichen alle im Home-Hypervisor befindlichen Dienste über den
EC2 Amazon Web Services-Dienst über eine kostenlose Instanz für Amazon Linux AMI 2018 mit
Libreswan ,
xl2tpd und mit ein wenig Verzerrung ...
Systemadministratoren eines traditionellen (Nicht-IT-) Unternehmens mit Erfahrung verfügen normalerweise nach einer Weile über eine eigene Servervirtualisierungsfarm zu Hause, um den Haufen von Lösungen vor Ort zu testen. Dies kann eine banale Nachahmung eines verteilten Zweigstellennetzwerks, das Testen einer integrierten Infrastruktur mit hoher Verfügbarkeit, die Bereitstellung neuer Versionen einiger Lösungen usw. sein.
Extern kann es von einem einfachen speichergepumpten Heim-PC mit integriertem Hypervisor und einem Consumer-NAS als iSCSI-Speicher (oder sogar als einfache virtuelle Maschine auf demselben PC) bis zu vollwertigen kleinen Rack-Mount-Servern reichen, die für kostengünstig abgeschriebene Steuergeräte gekauft wurden mit einem Stammbaum aus westlichen Rechenzentren, mit der gleichen BU tsiska für die Netzwerkkonnektivität und im Fibre Channel gleich stecken geblieben, auf dem Sekundärmarkt NAS gekauft, aber bereits eine Business Class.
Natürlich kann in unserer Zeit der Begeisterung für Clouds die gesamte Infrastruktur problemlos in Cloud-Rechenzentren bereitgestellt werden, aber dies ist vor allem aufgrund der Kosten immer noch nicht immer möglich. Es spielt keine Rolle, ob für die Tests mehrere leichte virtuelle Maschinen aus den verfügbaren Plänen erforderlich sind, aber was ist, wenn Sie im Dienst mehrere Dutzend oder sogar Hunderte separater „virtueller Maschinen“ mit einer Vielzahl von Diensten verdrehen müssen und außerdem ein Archiv haben möchten, damit Sie es jederzeit haben können Vor einem Jahr gab es eine Stichprobe, die sich in Konfigurationen / Einstellungen verdreht hat. Oder es besteht die Notwendigkeit, alle Fallstricke mit derselben Synchronisation zwischen ADDS und ADFS zu übertragen, bevor einige der vorhandenen Geschäftsdienste auf dasselbe MS Azure übertragen werden.
Das Hauptproblem in diesem Fall ist die Veröffentlichung (Weiterleitung) dieser gesamten Infrastruktur nach außen, damit Sie üben können, Benutzer von außen mit Ihrer "Server-Site" zu Hause oder mit Ihren eigenen "Cloud" -Diensten zu verbinden oder in Dienste von Drittanbietern usw. zu integrieren.
Es ist gut, wenn die Heimverbindung für einen Geschäftstarif ausgelegt ist. In diesem Fall gibt es keine Probleme mit eingehenden Anforderungen, und die IP-Adresse ist fast immer "weiß", statisch.
Was tun, wenn am Wohnort der übliche „Heimanbieter“ anwesend ist, der zusätzlich nur eine Adresse aus dem privaten Netzwerk bereitstellen kann? Oder wird eine weiße Adresse angegeben, aber traditionell alle eingehenden Nachrichten aus dem privilegierten (<1024) Portbereich abgeschnitten? Oder Sie sind ein blöder armer Student und können sich einfach keine monatliche Rate leisten, die für juristische Personen bestimmt ist. Oder müssen Sie häufig Ihren Wohnort wechseln und die "Habseligkeiten" Ihres virtuellen Servers auf den Buckel ziehen? Ein Sonderfall ist auch für Personen relevant, die außerhalb der GUS leben, wenn der Anbieter zwangsweise seine eigenen Geräte für die Verbindung zum Internet bereitstellt und Sie die Weiterleitung der benötigten Ports an die virtuelle Heimfarm außerhalb einfach nicht konfigurieren können.
Eine Lösung besteht darin, einen der VPN-Dienste von Drittanbietern zu verwenden. Leider erlauben nur wenige von ihnen die Erlaubnis eingehender Verbindungen in Bezug auf den Tunnel, meistens handelt es sich um einen separaten kostenpflichtigen Dienst. In diesem Fall ist die Auswahl an externen IP-Adressen sehr begrenzt, wenn Sie die Situation mit einer externen IP-Adresse in einem bestimmten Land testen möchten. Darüber hinaus gibt es in der Regel keine Garantie dafür, dass nicht gleichzeitig eine Reihe anderer VPN-Dienstclients an dieser Adresse hängen , oder es wird für eine lange Zeit statisch sein, was für das Einrichten von Service-Subdomain-Einträgen in DNS wichtig ist.
Es lohnt sich auch (IMHO), trotz einiger perverser Methoden, Ihren eigenen „virtuellen“ Router auf einer externen Cloud-Plattform bereitzustellen, mit der Möglichkeit, einen VPN-Tunnel von der Home-Hypervisor-Farm zu dieser virtuellen Maschine in der Cloud zu konfigurieren, wobei die erforderlichen eingehenden Verbindungen von der externen Netzwerkschnittstelle weitergeleitet werden Clouds zu Hause Hypervisor-Dienste. Und im Idealfall fast nichts für das Ganze zu bezahlen.
Nachdem ich kürzlich meinen Job verloren hatte und damit Zugang zu einer warmen und komfortablen Testfarm für Unternehmen hatte, aber im Gegenzug viel Zeit erhielt, um meine Fähigkeiten zu aktualisieren, beschloss ich, den Diensten meines Heimhypervisors die Möglichkeit zu geben, eingehende Kundenverbindungen zu sehen.
Der Autor dieser Zeilen
„liebt alle Arten von Infrastrukturperversionen“ . Daher verwenden wir als virtueller Router die kostenlose Instanz von Amazon Web Services (AWS) EC2 t2.micro für Linux, die anstelle von AWS: VPC (theoretisch) etwas mehr Flexibilität beim Debuggen und bei den Funktionen bietet und die Topologie dieser VPN-Perversion wird unten gezeigt:
Was sehen wir hier?
Unter Linux ist eine kostenlose virtuelle Maschine (Instanz) (750 Stunden pro Monat im Jahr) unter Linux verfügbar, die in AWS: EC2 bereitgestellt wird. Eingehende Anrufe von einigen Benutzern Ihrer Heimdienste fallen an die externe weiße IPv4-Adresse von Elastic IP. Durch die eingehenden (eingehenden) Regeln in den „Sicherheitsgruppen“ werden die Ports, die wir benötigen, der Netzwerkschnittstelle der Instanz zugeordnet. Anschließend werden Pakete dieser Anforderungen über iptables durch den IPSec-Tunnel geleitet Eine virtuelle Maschine für Windows 2016, bei der RRAS mithilfe des Routings zum gewünschten Dienst in der virtuellen Heimfarm gelangt. Besonderes Augenmerk legen wir auf das gleichzeitige Vorhandensein von drei NATs: eines in AWS Linux, eines auf dem Router für das Büronetzwerk und eines implizit auf dem Heimrouter.
In diesem (meinem) Fall spielt eine virtuelle Maschine unter Windows Server 2016 die Rolle eines Routers zur Simulation eines Büronetzwerks und seiner Serverplattform. MS WAP wird auf diesem Computer in Verbindung mit einem separaten Computer mit MS ADFS und anderen bereitgestellt, sodass es kein Problem gibt, ihn durch ein anderes Betriebssystem oder zu ersetzen sogar ein hausgemachtes Stück nach Geschmack. Mit Windows RRAS werden die Dinge übrigens auf dem Weg kompliziert, während ich mich mit verschiedenen unangenehmen Momenten befassen musste (über die unten). Wenn Sie also MS Windows Server als Router nicht mögen, ist es mit einem anderen Betriebssystem möglicherweise einfacher.
Zuerst erstellen wir ein AWS-Konto, falls Sie noch kein Konto haben. Es gibt keine Probleme beim Erstellen des Kontos selbst. Sie müssen lediglich die Details Ihrer Plastikkarte angeben, von der 1 USD als Scheck abgebucht (und dann zurückgegeben) wird.
Hier sind nur zwei Punkte zu erwähnen:
- Gehen Sie unbedingt zu AWS: IAM (Identity and Access Management) und aktivieren Sie MFA (Multi-Factor Authentication) für Ihr neues Konto, und noch besser, wie AWS empfiehlt - erstellen Sie auch ein separates Konto bei MFA und arbeiten Sie weiterhin an der Einschränkung der entsprechenden Rechte. sie. Andernfalls könnten Sie in eine unangenehme Situation geraten, wenn ein Trojaner AWS-Anmeldeinformationen von Ihrem PC stiehlt und beispielsweise jemand auf Ihre Kosten teure Hochleistungsinstanzpläne aus Ihrem Herzen abbaut ...
- Aus praktischen Gründen wird empfohlen, eine Budgetbenachrichtigung einzurichten. Dies erfolgt in den Kontoeinstellungen, der entsprechende Menüpunkt heißt "Billing & Cost Management Dashboard". Wählen Sie im daraufhin angezeigten Fenster links den Eintrag „Budgets“ aus und konfigurieren Sie das geplante Monatsbudget mithilfe des integrierten Assistenten nach Belieben. Vergessen Sie nicht, dort eine Warnung einzurichten: Bei Überschreitung des angegebenen Betrags erhalten Sie sofort eine Nachricht. Dies ist nützlich, wenn Sie zuvor noch nicht mit AWS gearbeitet haben und Angst haben, im Verlauf Ihrer Experimente versehentlich eine runde Summe zu erhalten.
Als nächstes brauchen wir
AWS: EC2 .
Einer der wichtigsten Schritte ist die Auswahl der AWS-Region (im Wesentlichen eines Rechenzentrums), in der wir unsere virtuelle Maschine bereitstellen möchten. Die Platzierung wirkt sich direkt auf den geografischen Standort Ihres „virtuellen Routers“ und damit auf die Netzwerkverzögerung bei der Arbeit mit ihm aus. Das ist wichtig, weil AWS bietet keine Live-Migration zwischen Regionen (der integrierte
AWS Server-Migrationsdienst kann nur etwas in die AWS-Cloud selbst migrieren). Im Falle eines Platzierungsfehlers ist es einfacher, eine neue Instanz am gewünschten Speicherort erneut zu erstellen. Alternativ müssen Sie das Image aus der Instanz (Image, integriertes EC2) in
AWS: S3 (Speicherdienst) entfernen und von dort aus dieses Image in die EC2-Instanz in der neuen Region ziehen. In meinem Fall wurde ursprünglich die Region
Frankfurt ausgewählt:
Wir erstellen eine neue Instanz und wählen links die Option
"Nur kostenlose Ebene" aus, wodurch die vorgeschlagene Liste der Bilder auf nur freie beschränkt wird. Ich habe mich für
"Amazon Linux AMI 2018" entschieden (
mehr über Linux-Distributionen in AWS), weil unter "Amazon Linux 2 AMI" funktioniert xl2tpd aufgrund der Art des von Amazon zusammengestellten Kernels nicht ordnungsgemäß.
Sie können aus der bereitgestellten Liste jedes andere Linux-Image auswählen, das Ihnen vertraut ist. Sie können auch tiefer in den
AWS Marketplace einsteigen und dort nach alternativen Images suchen. Lesen Sie einfach die Kommentare zu den Kosten sorgfältig durch: Das Image selbst und die Computerressourcen können kostenlos sein, aber Sie müssen extra für Speicherplatz usw. bezahlen.
Wir wählen den vorgeschlagenen Typ
"t2.micro" aus . Er bietet 1 vCPU, 1 GB Speicher,
8 bis 30 GB (SSD / Magnetic) Speicherplatz und 750 Stunden Arbeit pro Monat für ein Jahr. Genug für unseren „virtuellen Router“. Es ist erwähnenswert, dass für alle Instanzen freier Speicherplatz und Arbeitszeit aufgewendet werden. Bei finanziellen Schwierigkeiten müssen Sie also nicht mehr erstellen / ausführen, als Sie sich leisten können, außer kostenlos.
Klicken Sie in den Assistenten "Weiter ...". Im dritten Schritt belassen wir alle Standardwerte. Im vierten Schritt stimmen wir den vorgeschlagenen 8 Gigabyte SSD-Standardfestplatte zu. Die Instanz beginnt mit der Schaltfläche Überprüfen und Starten:
Danach erhalten wir ein Fenster mit einer Meldung zum Erstellen eines neuen Schlüsselpaars für die Verbindung mit unserem über SSH und einem Vorschlag, dieses Paar zu benennen und den privaten Schlüssel im * .pem-Format herunterzuladen. Wir werden es in Zukunft wirklich brauchen, daher ist es ratsam, es sofort an einem sicheren Ort aufzubewahren. Wenn diese Datei verloren geht, können Sie keine Remoteverbindung zu Instanzen herstellen, die sie verwenden. In EC2 gibt es keine Möglichkeit, es für eine vorhandene Instanz erneut zu generieren. Die einzige Möglichkeit besteht darin, die Instanzdiskette mit einer anderen Instanz zu verbinden, die Zugriff hat, und anschließend die Schlüssel zu bearbeiten.
Nach einer Weile wird die Instanz gestartet und verfügt über eine interne (private) und externe (öffentliche) IPv4-Adresse sowie zwei entsprechende DNS-Namen.
Konfigurieren Sie Sicherheitsgruppen sofort, um den Datenverkehr für die von Ihnen benötigten Dienste sicherzustellen:
Wir benötigen die offenen eingehenden Ports 500, 1701, 4500 UDP und 4500 TCP für die Organisation des IPSec L2TP-VPN-Tunnels, HTTP und HTTPS für die Veröffentlichung von Home Farm-Diensten. Der externe Zugriff auf die Instanz über SSH wurde beim Erstellen der Instanz automatisch erstellt, da EC2 enthält im Wesentlichen keinen integrierten Zugriff auf die Konsole der virtuellen Maschine über die Webschnittstelle. Es gibt nur die Möglichkeit, den Bildschirm anzuzeigen:
Es wird empfohlen, den Zugriff über VPN und SSH nur von Ihrer privaten IP-Adresse aus zu konfigurieren. Die Reihenfolge der Regeln in Sicherheitsgruppen spielt keine Rolle.
Da wir mehrere NAT-Dokumentationen verwenden, empfiehlt AWS, die
Überprüfung der Netzwerkquelle / des Netzwerkziels in diesem Fall zu deaktivieren:
Da wir IPSec-Tunneling und nicht Transport verwenden, ist diese Einstellung für uns nicht sehr sinnvoll, aber für alle Fälle ist es besser, sie auszuschalten.
Stellen Sie über SSH eine Verbindung zu unserer Instanz her. Wenn Sie einen SSH-Grafikclient verwenden, z. B. PuTTY, um eine Verbindung herzustellen, hilft Ihnen die integrierte Hilfe für die Verbindung, die von RMB auf der Instanz aufgerufen wird -> Verbinden:
Amazon Linux verwaltet einen Stammbaum von RHEL und CentOS, daher wird der yum-Paketmanager verwendet.
Alle unten beschriebenen Vorgänge müssen mit einer Eskalation von Berechtigungen ausgeführt werden. Daher stellen wir ihnen sudo voran oder arbeiten nur als root.
Erstes Update:
Als Software zur Organisation eines VPN-Servers verwenden wir eine Kombination aus Libreswan und xl2tpd.
LibreSwan (Fork von Openswan und ein Analogon von strongSwan) ist eine beliebte Implementierung von VPN IPSec und IKE (Internet Key Exchange). Es kann verschiedene Arten von NAT und ihre Kombinationen korrekt umgehen, was besonders wichtig ist, wenn das IPSec-Tunneling organisiert wird.
xl2tpd ist ebenfalls weit verbreitet. Sein Hauptvorteil ist die integrierte Fähigkeit, Clientverbindungsparameter beim
Herstellen einer Verbindung über ppp zu authentifizieren und zu übertragen (z. B. IP-Adressen, Standardrouteneinstellungen, DNS-Server usw.), wodurch die Notwendigkeit einer zusätzlichen DHCP- und Radius-Bereitstellung für unsere überflüssig wird einfache Aufgaben.
Da xl2tpd nicht in den Standard-Amazon Linux-Repositorys enthalten ist, müssen wir EPEL (Extra Packages for Enterprise Linux) aktivieren:
Installieren Sie die erforderlichen Pakete:
Aktivieren Sie das Routing auf Kernelebene:
In die Datei
/etc/sysctl.conf schreiben
wir :
net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.lo.secure_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.eth0.secure_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0
Deaktivieren Sie rp_filter in der aktuellen Sitzung, um keinen Neustart
durchzuführen :
Wir übernehmen die Einstellungen und prüfen die Verfügbarkeit des Routings:
Wir müssen sicherstellen, dass eingehende (in Bezug auf die öffentliche Schnittstelle der Instanz) Pakete von den Ports der erforderlichen Dienste an unseren zukünftigen IPSec-Tunnel weitergeleitet werden. Dazu ist es nicht nur erforderlich, diese Pakete zu de-
NATen , sondern auch die Maskierung auf der
ppp0- Schnittstelle
durchzuführen .
Wir werden hierfür die integrierten
iptables- Funktionen verwenden, die im Fall von Amazon Linux zunächst so konfiguriert sind, dass jeglicher Datenverkehr in jede Richtung vollständig zugelassen wird:
DNAT der erforderlichen Ports erstellen:
Leiten Sie alle Pakete, die an diese Ports kamen, an die Windows-Gate-Adresse weiter:
Maskieren Sie diese Pakete:
Es ist ratsam, die iptables-Regeln beizubehalten, damit sie beim Neustart der Instanz automatisch verschärft werden:
In diesem Fall verwenden wir den DNAT (Destination NAT) des erforderlichen TCP-Ports von der Netzwerkschnittstelle eth0 der Instanz in Richtung der IPv4-Adresse 10.100.0.2, die die Adresse auf der PPP-Schnittstelle des RRAS-Dienstes unseres Windows-Gates im Home-Hypervisor ist.
Das Folgende ist ein sehr wichtiger Punkt: Da die Dienste im Hypervisor in der Lage sein müssen, auf von der AWS-Instanz empfangene Anforderungen zu antworten, muss vor dem Senden des Pakets eine Maskierung (Ersetzen der Absenderadresse) auf der
ppp0- Schnittstelle der Instanz
bereitgestellt werden. Andernfalls geht die Antwort in eine völlig andere Richtung: von Das Windows-Gate im Hypervisor führt hinter dem IPSec-Tunnel direkt zum Standard-Router (Home-Router). Dadurch wird es natürlich auf der Clientseite des Dienstes gelöscht, als stamme es von einer nicht angeforderten Ressource. Wenn Maskierung im Paket-Header am Eingang zum VPN-Tunnel verwendet wird, ändert sich die Absenderadresse von der Adresse irgendwo im Internet zu der Adresse
ppp0 der Schnittstelle der AWS-Instanz: EC2, d. H. in meinem Fall um 10.100.0.1
Als Alternative zur Verwendung von iptables für andere Linux-Distributionen oder * NIX-Systeme können Sie das gute alte rinetd empfehlen, bei dem dies alles in der Regel in einer Zeile in der
Konfiguration rinetd.conf erfolgt :
<ip source> <port source> <ip destination> <port destination>
Das einzige, was in diesem Fall im Kernel aktiviert werden muss, ist die Möglichkeit des Routings / NAT-Verkehrs.
Es ist Zeit, Libreswan zu kochen.
Die Datei
/etc/ipsec.conf enthält Anweisungen zum Herunterladen aller .conf-Dateien von /etc/ipsec.d/. Daher erstellen wir eine neue Konfigurationsdatei im Verzeichnis /etc/ipsec.d/aws_vpn.conf und fügen sie hinzu:
config setup
Der Einfachheit halber verwenden wir die IPSec-Authentifizierung basierend auf einem gemeinsam genutzten Schlüssel (PSK) und nicht auf Zertifikaten. Daher müssen wir ihn explizit angeben. Die Datei
/etc/ipsec.secrets enthält Anweisungen zum Herunterladen aller .secrets-Dateien von
/etc/ipsec.d/ . Dort erstellen wir eine neue Datei
/etc/ipsec.d/aws_vpn.secrets und geben die PSK im folgenden Format an:
< 172...> %any : PSK "< PSK>"
Als Beispiel:
172.31.20.120 %any : PSK "Pa$$w0rd"
Da die ppp-Verbindung innerhalb des IPSec-Tunnels verwendet wird und es eine eigene Authentifizierung gibt, konfigurieren wir sie auch:
Wir geben den Benutzernamen und das Passwort in die Datei
/ etc / ppp / chap-secret im folgenden Format ein:
<user> * <password> *
Als Beispiel:
aws_user * Pa$$w0rd *
Bei der Verbindung mit dem ppp-Client können eine Reihe von Optionen übergeben werden, um die Netzwerkschnittstelle und die Routing-Tabelle zu konfigurieren.
Legen Sie in der Datei
/etc/ppp/options.xl2tpd die
folgenden Optionen fest:
Weil Wir müssen keine DNS-, Wins- usw. Adressen an den Client weitergeben. Dinge - alle anderen Optionen müssen auskommentiert werden.
Hier benötigen Sie eine Erläuterung der Konfiguration.
Das Standardverhalten für VPN-Verbindungen besteht darin, eine neue Standardroute in der Client-Tabelle zu installieren, die den gesamten Datenverkehr von dieser zum Internet zwingt, über den VPN-Server zu "gehen". In unserem Fall ist das falsch, weil Das Ziel des Windows-Gates besteht darin, einen simulierten Zugriff auf das Internet des dahinter liegenden virtuellen Büronetzwerks im Hypervisor bereitzustellen und die Ressourcen interner Dienste über AWS: EC2 nach außen zu veröffentlichen. Daher ist es irrational, den gesamten Datenverkehr über die Instanz an AWS: EC2 weiterzuleiten. Aus diesem Grund müssen Sie verhindern, dass eine VPN-Verbindung in RRAS die Standardroute (zu einem Heimrouter) ändert.
Es ist auch wichtig, die richtigen MTU- und MRU-Werte auszuwählen: Wir verwenden IPSec-Tunneling und eine zu große Nutzlast passt möglicherweise nicht in die Kapselungsgrenze, was zu Fragmentierung und höchstwahrscheinlich zu einem Fehler führt. Wenn dies angezeigt wird, versuchen Sie zunächst, diese Werte beispielsweise auf 1280 zu reduzieren. Die in der angegebenen Konfiguration angegebenen Werte sind mit dem Windows VPN-Client kompatibel.
Es bleibt xl2tpd zu konfigurieren
Wir konfigurieren alles Notwendige in der Konfigurationsdatei xl2tpd
/etc/xl2tpd/xl2tpd.conf :
[global] port=1701 ipsec saref = yes ; , ;debug tunnel = yes ;debug avp = yes ;debug network = yes ;debug state = yes ;debug tunnel = yes [lns default] name = AWSvpnServer ; ppp ip range = 10.100.0.2-10.100.0.2 ; ppp0 AWS:EC2 local ip = 10.100.0.1 require authentication = yes require chap = yes refuse pap = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
Wir überprüfen alles, was wir getan haben
Wir versuchen beide Dienste auszuführen und die Konfigurationen zu überprüfen:
service ipsec start service xl2tpd start ipsec verify
Möglicherweise werden Dienste bereits ausgeführt. In diesem Fall werden sie einfach neu gestartet.
Wenn alles in Ordnung ist, sollte die Ausgabe von ipsec verify dem Screenshot ähnlich sein:
Sie können xl2tpd interaktiv debuggen, indem Sie es mit dem Schalter -D ausführen und mit dem
Bildschirmdienstprogramm in einem separaten „Fenster“ des SSH-Terminals aufhängen:
In diesem Fall tritt der xl2tpd-Prozess nicht in den Hintergrund, sondern zeigt alle seine Aktivitäten auf dem Terminalbildschirm an.
Bei Problemen müssen Sie die Debugging-Optionen in den Konfigurationen auskommentieren (siehe Kommentare) und den Inhalt der Systemprotokolle und der Datei
/var/log/pluto.log überprüfen . Beachten Sie auch den Inhalt der Option
virtual_private / virtual-private in der Datei
/etc/ipsec.conf . Sie listet alle privaten Netzwerke auf, die für den Datenaustausch über IPSec verfügbar sind. Wenn Sie aus irgendeinem Grund eine eigene Adressierung haben, z. B. einen eigenen Pool weißer IPv4-Adressen verwenden, sollten Sie Änderungen an diesem Parameter vornehmen.
Fahren wir mit dem letzten Schritt fort: Einrichten des RRAS-Dienstes im Windows-Gate und Überprüfen der Veröffentlichung von Diensten aus dem Internet
Es wird davon ausgegangen, dass Ihr Heimhypervisor über eine virtuelle Maschine unter Windows 2012R2 oder höher verfügt, die im grafischen Modus (Desktop) bereitgestellt wird, und dass diese virtuelle Maschine zwei Netzwerkadapter enthält: Einer "schaut" in das Heimnetzwerk und hat einen Heimrouter als Standardroute und das andere in ein virtuelles lokales "Büro" -Netzwerk, in dem Dienste außerhalb veröffentlicht werden. Eine Windows-Domäne ist optional, es sei denn, die Dienste selbst erfordern dies.
Wir installieren alle erforderlichen Rollen mithilfe des Server-Managers oder des Cmdlets PowerShell
Install-WindowsFeature :
Hier demonstriere ich die Installation von Rollen durch Grafiken, da es dann noch viel bequemer ist, den Setup-Assistenten vom Server-Manager aus aufzurufen und den RRAS-Dienst selbst im Zeitplan zu konfigurieren, was uns mit der guten alten Oberfläche aus der Zeit von Windows Server 2003 gefallen wird:
Klicken Sie auf Ihrem Server auf RMB, wählen Sie
"Routing und RAS konfigurieren und aktivieren" und konfigurieren Sie dann manuell:
Sie können alle Dohlen auswählen, den Assistenten abschließen und den Dienst starten:
Lassen Sie uns zunächst unser virtuelles lokales Netzwerk außerhalb freigeben. Wir gehen zu IPv4-> NAT und erstellen eine neue Schnittstelle, da die vorhandene Schnittstelle, auf der NAT implementiert wird, die externe Schnittstelle (die im Internet bzw. in Ihrem Heimnetzwerk angezeigt wird) ausgewählt, als öffentlich markiert und NAT darauf aktiviert wird:
Wir überprüfen, wie der Datenverkehr aus dem virtuellen LAN durch unser Gate abfließt. Wir müssen die Windows-Firewall noch nicht konfigurieren.
Wenn alles in Ordnung ist, werden wir endlich das schaffen, wofür wir gekämpft haben, eine VPN-Verbindung zu unserer AWS-Instanz und die Veröffentlichung unserer Dienste überprüfen. Wir gehen im RRAS-Snap-In zu
„Netzwerkschnittstellen“ und erstellen eine neue Demand-Dial-Schnittstelle mit einem beliebigen Namen:
Wählen Sie sofort die L2TP-Verbindung aus, damit unsere neue Schnittstelle nicht automatisch versucht, den VPN-Typ zu ermitteln, und dadurch eine schnellere Verbindung herstellt:
Weiter im Assistenten geben wir die öffentliche Adresse unserer Cloud an (in meinem Fall Elastic IP). Lassen Sie in den nächsten Schritten alles so wie es ist, weil Wir benötigen keine Site-to-Site-Verbindung:
Geben Sie das Benutzerkonto an, unter dem wir die ppp-Verbindung konfiguriert haben (in der Datei
/ etc / ppp / chap-secret ). Es ist kein Domainname erforderlich:
Der Assistent erstellt eine neue Verbindung. Jetzt bleibt es zu konfigurieren. Wir werden das Leerlaufzeitlimit (Leerlaufzeit) anpassen, das veraltete CHAP zugunsten von nur MS-CHAPv2 entfernen und den PSK-Schlüssel in den "Erweiterten Eigenschaften" angeben (der für xl2tpd in der Datei /etc/ipsec.d/aws_vpn festgelegt wurde). Geheimnisse) und IPv6 entfernen:
Nach dem Erstellen einer neuen Schnittstelle müssen Sie auch die Eigenschaften des RRAS-Dienstes selbst aufrufen, Ihre IPSec-Richtlinie für L2TP aktivieren und Ihr PSK angeben. Sie werden aufgefordert, den RRAS-Dienst neu zu starten.
Es scheint, dass alles sicher eine neue Oberfläche aufgerufen werden kann und die Arbeit genießen kann. Aber nein. Aufgrund der Tatsache, dass wir NAT auf der Seite der AWS: EC2-Instanz verwendet haben, kann der Windows-VPN-Client keine Verbindung zu einem solchen Nat-Traversal-Knoten herstellen. Dies gilt sowohl für Client-Versionen (bis zum Zeitpunkt des Schreibens dieses Artikels des Windows 10-Builds) als auch für Server-Versionen.
Glücklicherweise gibt es eine offizielle Lösung für dieses Problem in Form von Änderungen in der Registrierung der IPSec Policy Service-Einstellungen, gefolgt von einem Neustart:
An die Adresse
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgentErstellen Sie einen DWORD-Schlüssel (32-Bit)
Angenommen, UDPEncapsulationContextOnSendRule = 2und starten Sie unser Windows Gate neu.
Der RRAS-Dienst ist leider für seine launische Konfiguration und Bedienung bekannt und führt auch nach einem Neustart einen verzögerten Start durch. So können Sie es nach einem Neustart beschleunigen.
Wenn alles richtig gemacht wurde, funktioniert die Verbindung innerhalb von 5-10 Sekunden.
Es bleibt die Veröffentlichung der erforderlichen Ressourcen auf dem Windows-Gate selbst.
Für den Test werden wir die Veröffentlichung des Webservers ausarbeiten. Schauen Sie sich zuerst unseren IPSec-Tunnel und die iptables-Regeln an.
Mit zitternden Händen prüfen wir von einem beliebigen PC aus, der mit dem Internet verbunden ist:
Wow, es funktioniert ...
Während der Installation der erforderlichen Rollen wurde der "native" MS IIS zwangsweise installiert, aber wir möchten, dass es noch einfacher wird. Auf einer Windows-Plattform ist
HFS (HTTP File Server) dafür gut geeignet - es ist kostenlos, erfordert keine Installation, gibt eine bestimmte Seite und einen bestimmten HTTP-Header an und kann an einem beliebigen Port arbeiten (standardmäßig ist es 8080, in unserem Fall muss es also auf 80 neu konfiguriert werden). Außerdem wird sofort in die Konsole geschrieben, woher die Verbindung stammt. Dies ist sehr praktisch, um die Veröffentlichung vieler Webressourcen auf der Windows-Plattform zu debuggen. Um es zu verwenden, müssen Sie zuerst die MS IIS-Site stoppen, um den eingebetteten Server vom erforderlichen Port zu trennen. Da wir die MS IIS-Verwaltungskonsole nicht installieren möchten (die MS IIS 6-Konsole ist aus Kompatibilitätsgründen vorhanden, IIS 7+ kann jedoch nicht über sie gesteuert werden), führen wir dies über PowerShell aus:
Stop-WebSite -Name "Default Web Site"
oder einfach über das iisreset-Verwaltungsdienstprogramm:
iisreset /stop
Danach müssen Sie eingehenden Datenverkehr zu Port 80 in der integrierten Windows-Firewall zulassen.
Wir starten HFS und überprüfen:
Alles ist großartig. Wir haben erreicht, dass Sie von überall im Internet den Webserver, der in unserem Haus lebt, als virtuelle Maschine in einem beliebigen Hypervisor sehen können.
Der letzte Schliff: Wir bringen RRAS bei, alle derartigen Anfragen von außen an das virtuelle Büronetzwerk weiterzuleiten, wo wir der Legende nach einen anderen Webserver haben.
Dazu rufen wir erneut das RRAS-Verwaltungs-Snap-In in IPv4-> NAT und RMB auf unserer VPN-Schnittstelle auf. Dort wählen wir die Registerkarte
„Dienste und Ports“ aus , markieren sie in der Liste der Webserver und geben den Webserver im internen virtuellen Netzwerk an, auf dessen Ressourcen wir veröffentlichen möchten Internet:
Klicken Sie auf OK und ... alles ist fertig. Wir überprüfen - alles sollte gut funktionieren.
Auf diese einfache Weise können Sie schnell fast alle Dienste und Ressourcen veröffentlichen, von Websites über Mailserver bis hin zu komplexen Integrationen. Für die meisten von ihnen benötigen Sie natürlich eine eigene DNS-Domain, in der Sie Subdomains erstellen und die erforderlichen Einträge bearbeiten können. Es ist auch ratsam, SSL-Zertifikate zum Veröffentlichen von Webressourcen zu verwenden.
Dank LetsEncrypt und ähnlichen ACME-kompatiblen Diensten kann dies völlig kostenlos und mit automatischer Aktualisierung erfolgen.
Wenn Sie die Instanz neu starten, ändert sich die öffentliche IPv4-Adresse nicht - nur wenn sie gestoppt wird. Es wird jedoch weiterhin empfohlen, eine statische IPv4-Adresse in AWS: EC2 zu verwenden. Statisch in dem Sinne, dass Ihre Instanz beim Ausschalten dieser Instanz zugewiesen bleibt und nicht in den allgemeinen freien Pool fällt. Dies ist natürlich erforderlich, um nicht jedes Mal die Neukonfiguration von DNS-Einträgen in Domänen zu stören, und niemand hat TTL mit Caching abgebrochen. Es kostet viel Geld und wird, wie oben bereits erwähnt,
Elastic IP genannt .
Primitive Prozessautomatisierung
Abschließend möchte ich eine weitere großartige Funktion von AWS erwähnen: EC2 - schnelle Konfiguration der bereitstellbaren Instanz. In AWS: EC2 gibt es viele schnelle Bereitstellungsoptionen, bis hin zu speziellen (und recht komplexen, aber sehr leistungsfähigen) Diensten. Die einfachste: In Schritt 3 des Assistenten zum Erstellen einer neuen Instanz befindet sich unten das Feld
"Benutzerdaten" . Sie können ein Bash-Skript oder sogar PowerShell (im Fall einer Instanz unter Windows) einfügen. Dieses Skript wird unmittelbar nach dem Erstellen der Instanz automatisch ausgeführt.
Das heißt, Sie können alle oben genannten Befehle und Konfigurationen leicht ändern, um Ihr eigenes Bash-Skript zu erstellen und damit schnell einen solchen virtuellen AWS: EC2-Router zu starten.
Erfahren Sie mehr über diese Funktion .
Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Artikel zu lesen.