Nous publions tous les services situés dans l'hyperviseur domestique via le service
EC2 Amazon Web Services via une instance gratuite pour Amazon Linux AMI 2018 en utilisant
libreswan ,
xl2tpd et avec un peu de distorsion ...
Les administrateurs système d'une entreprise traditionnelle (non informatique) ayant de l'expérience, généralement après un certain temps, ont leur propre batterie de serveurs de virtualisation à la maison pour tester le tas de solutions sur le terrain. Cela peut être une imitation banale d'un réseau de succursales réparties, le test d'une infrastructure intégrée de haute disponibilité, le déploiement de nouvelles versions de certaines solutions, etc.
À l'extérieur, il peut passer d'un simple ordinateur domestique à mémoire de pompage avec un hyperviseur intégré et un NAS de qualité grand public comme stockage iSCSI (ou même comme une simple machine virtuelle sur le même PC) à des serveurs à montage en rack de petite taille à part entière achetés pour des unités de commande moins chères. avec un pedigree des centres de données occidentaux, avec la même BU tsiska pour la connectivité réseau et coincé dans le Fibre Channel même, acheté dans le NAS du marché secondaire, mais déjà une classe affaires.
Bien sûr, à l'ère de l'engouement pour les nuages, toute l'infrastructure peut facilement être déployée dans des centres de données cloud, mais ce n'est toujours pas toujours possible, principalement en raison du coût. Peu importe si les tests nécessitent plusieurs machines virtuelles légères à partir des plans disponibles, mais qu'en cas de service, vous devez tordre plusieurs dizaines voire des centaines de «machines virtuelles» distinctes avec une grande variété de services, et vous voulez également avoir une archive afin de pouvoir l'avoir à tout moment il y avait un échantillon qui s'est tordu dans les configurations / paramètres il y a un an. Ou il est nécessaire de transférer tous les pièges avec la même synchronisation entre ADDS et ADFS avant de transférer certains des services commerciaux existants vers le même MS Azure.
Le principal problème dans ce cas est la publication (transfert) de toute cette infrastructure vers l'extérieur, afin que vous puissiez vous entraîner à connecter des utilisateurs de l'extérieur à votre "site serveur" domestique ou à vos propres services "cloud", ou à l'intégration avec des services tiers, etc.
C'est bien si la connexion domestique est conçue pour un tarif professionnel, dans ce cas il n'y a pas de problème avec les demandes entrantes, et l'adresse IP est presque toujours "blanche", statique.
Mais que faire lorsque le prestataire «domicile» habituel est présent sur le lieu de résidence, qui en plus ne peut fournir qu'une adresse du réseau Privé. Ou donnera-t-il une adresse blanche, mais coupe-t-il traditionnellement tous les entrants de la plage de ports privilégiés (<1024)? Ou vous êtes un pauvre étudiant ringard et ne pouvez tout simplement pas vous permettre un tarif mensuel conçu pour les personnes morales. Ou devez-vous souvent changer de lieu de résidence, en faisant glisser les «effets personnels» de votre serveur virtuel vers la bosse? Un cas spécial est également pertinent pour ceux qui vivent en dehors de la CEI, lorsque le fournisseur fournit de force son propre équipement pour se connecter à Internet et que vous ne pouvez tout simplement pas physiquement configurer la redirection des ports dont vous avez besoin vers la ferme virtuelle domestique à l'extérieur.
Une solution consiste à utiliser l'un des services VPN tiers. Malheureusement, peu d'entre eux autorisent les connexions entrantes par rapport au tunnel, le plus souvent c'est un service payant séparé. Dans ce cas également, le choix des adresses IP externes sera très limité si vous souhaitez tester la situation avec la présence d'une adresse IP externe dans un pays particulier, en outre, en règle générale, il n'y a aucune garantie qu'en même temps, un certain nombre d'autres clients de services VPN ne s'accrochent pas à cette adresse , ou il restera statique pendant longtemps, ce qui est important pour la configuration des enregistrements de sous-domaine de service dans DNS.
Il est également intéressant (à mon humble avis), bien que quelques méthodes perverties, soient de déployer votre propre routeur «virtuel» sur une plate-forme de cloud externe avec la possibilité de configurer un tunnel VPN de la ferme d'hyperviseur domestique vers cette machine virtuelle dans le cloud, avec les connexions entrantes nécessaires transmises à partir de l'interface réseau externe services de cloud to home hypervisor. Et idéalement, pour ne rien payer pour le tout.
Ayant récemment perdu mon emploi, et avec lui l'accès à une ferme de test d'entreprise chaleureuse et confortable, mais en retour, j'ai reçu beaucoup de temps libre pour mettre à jour mes compétences, j'ai décidé de donner aux services de mon hyperviseur à domicile la possibilité de voir les connexions client entrantes.
L'auteur de ces lignes
"aime toutes sortes de perversions d'infrastructure" , donc en tant que routeur virtuel, nous utiliserons l'instance gratuite Amazon Web Services (AWS) EC2 t2.micro pour Linux, qui au lieu d'AWS: VPC (en théorie) donnera un peu plus de flexibilité dans le débogage et les fonctionnalités , et la topologie de cette perversion VPN est présentée ci-dessous:
Que voyons-nous ici?
Il existe une machine virtuelle (instance) gratuite (750 heures de travail par mois pendant l'année), sous Linux, déployée dans AWS: EC2. Les appels entrants de certains utilisateurs de vos services à domicile tombent sur l'adresse IPv4 blanche externe d'Elastic IP, puis via les règles entrantes (entrantes) dans les «groupes de sécurité», les ports dont nous avons besoin sont mappés vers l'interface réseau de l'instance, puis les paquets de ces demandes via iptables passent par le tunnel IPSec pour une machine virtuelle pour Windows 2016, où, à l'aide du routage, RRAS accède au service souhaité dans la batterie de serveurs virtuelle domestique. Nous accordons une attention particulière à la présence de trois NAT à la fois: un dans AWS Linux, un sur le routeur «réseau de bureau» et un autre, implicite, sur le routeur domestique.
Dans ce (mon) cas, une machine virtuelle sous Windows Server 2016 joue le rôle d'un routeur pour simuler un réseau de bureau et sa plate-forme de serveur, MS WAP y est déployé en conjonction avec une machine distincte avec MS ADFS et autres, donc il n'y a aucun problème à la remplacer par un autre OS même une pièce maison au goût. Avec Windows RRAS, en passant, les choses se compliquent en cours de route, tout au long du chemin, j'ai dû faire face à divers moments désagréables (dont ci-dessous), donc si vous choisissez de ne pas aimer MS Windows Server en tant que routeur, alors avec un autre système d'exploitation, cela peut être plus facile.
Nous allons d'abord créer un compte AWS si vous n'en avez toujours pas. Il n'y a aucun problème avec la création du compte lui-même, il vous suffit d'indiquer les détails de votre carte plastique, à partir de laquelle 1 USD sera débité (puis retourné) comme chèque.
Seuls deux points doivent être mentionnés ici:
- Assurez-vous d'accéder à AWS: IAM (gestion des identités et des accès) et activez MFA (authentification multifacteur) pour votre nouveau compte, ou mieux encore, comme le recommande AWS - créez également un compte distinct avec MFA et continuez à travailler en limitant les droits correspondants. elle. Sinon, vous risquez de vous retrouver dans une situation désagréable lorsqu'un cheval de Troie vole les informations d'identification AWS de votre PC et, par exemple, quelqu'un mine le mien à vos frais sur des plans d'instance haute performance coûteux ...
- Pour des raisons pratiques, il est recommandé de configurer une alerte budgétaire. Cela se fait dans les paramètres du compte, l'élément de menu correspondant est appelé «Tableau de bord de facturation et de gestion des coûts». Dans le panneau qui s'ouvre, sélectionnez l'élément «Budgets» à gauche et configurez le budget mensuel prévu à votre goût à l'aide de l'assistant intégré. N'oubliez pas d'y mettre en place une alerte: en cas de dépassement du montant spécifié, vous recevrez immédiatement un message. Cela est utile si vous n'avez jamais travaillé avec AWS auparavant et que vous avez peur d'obtenir accidentellement une somme ronde au cours de vos expériences.
Ensuite, nous avons besoin d'
AWS: EC2 .
L'une des étapes les plus importantes consiste à sélectionner la région AWS (essentiellement un centre de données) dans laquelle nous voulons déployer notre machine virtuelle. Le placement affectera directement l'emplacement géographique de votre «routeur virtuel», et donc le retard du réseau lorsque vous travaillez avec lui. Ceci est important car AWS ne fournit pas de migration en direct entre les régions (le
service de migration de serveur AWS intégré ne peut migrer que quelque chose vers le cloud AWS lui-même) et en cas d'erreur de placement, il est plus facile de recréer une nouvelle instance à l'emplacement souhaité. Sinon, vous devrez supprimer l'image de l'instance (Image, EC2 intégré) dans
AWS: S3 (service de stockage) et à partir de là , tirer cette image dans l'instance EC2 dans la nouvelle région. Dans mon cas, la région de
Francfort a été initialement sélectionnée:
Nous créons une nouvelle instance, sélectionnez l'option
"Free tier only" à gauche, ce qui limitera la liste d'images proposée aux seules images gratuites. J'ai choisi
"Amazon Linux AMI 2018" (
plus sur les distributions Linux dans AWS), car sur "Amazon Linux 2 AMI" xl2tpd ne fonctionne pas correctement en raison de la nature du noyau assemblé par Amazon.
Vous pouvez choisir n'importe quelle autre image Linux que vous connaissez dans la liste fournie. Vous pouvez Ă©galement aller plus loin dans
AWS Marketplace et y chercher des images alternatives, lisez attentivement les commentaires sur le coût: l'image elle-même et les ressources informatiques peuvent être gratuites, mais vous devrez payer un supplément pour l'espace disque, etc.
Nous sélectionnons le type proposé
«t2.micro» , il fournit 1 vCPU, 1 Go de mémoire, 8-30 Go (SSD / magnétique) d'espace disque et 750 heures de travail gratuitement chaque mois pendant un an. Assez pour notre «routeur virtuel». Il convient de noter que l'espace disque et le temps de travail sont consacrés à toutes les instances, donc en cas de difficultés financières, vous n'avez pas besoin de les créer / exécuter plus que vous ne pouvez vous le permettre, sauf gratuitement.
Cliquez dans l'assistant «Suivant ...», à la 3e étape, nous laissons toutes les valeurs par défaut, à la 4e, nous sommes d'accord avec les 8 gigaoctets de disque SSD par défaut proposés et l'instance commence avec le bouton Review and Launch:
Après cela, nous aurons une fenêtre avec un message sur la création d'une nouvelle paire de clés pour se connecter à la nôtre via SSH et une proposition pour nommer cette paire et télécharger la clé privée au format * .pem. Nous en aurons vraiment besoin à l'avenir, il est donc conseillé de le conserver immédiatement en lieu sûr. Si ce fichier est perdu, vous perdrez la possibilité de vous connecter à distance aux instances l'utilisant. Dans EC2, il n'y a aucun moyen de le régénérer à nouveau pour une instance existante, le seul moyen est de connecter le disque d'instance à une autre instance qui a accès et à la modification de clé ultérieure.
Après un certain temps, l'instance sera lancée, elle aura une adresse IPv4 interne (privée) et externe (publique), ainsi que deux noms DNS correspondants.
Configurez immédiatement les groupes de sécurité pour assurer le flux de trafic pour les services dont vous avez besoin:
Nous aurons besoin des ports entrants ouverts 500, 1701, 4500 UDP et 4500 TCP pour organiser le tunnel VPN IPSec L2TP, HTTP et HTTPS pour publier les services de la ferme de la maison, l'accès externe à l'instance via SSH a été créé automatiquement lors de la création de l'instance, car EC2 ne contient essentiellement aucun accès intégré à la console de la machine virtuelle via son interface Web. Il n'y a que la possibilité de visualiser l'écran:
Il est conseillé de configurer l'accès via VPN et SSH uniquement à partir de votre adresse IP domestique. L'ordre des règles dans les groupes de sécurité n'a pas d'importance.
Étant donné que nous utiliserons plusieurs documentations NAT, AWS recommande de désactiver la
«vérification de la source / destination du réseau» dans ce cas:
Étant donné que nous utiliserons le tunneling IPSec et non le transport, ce paramètre n'a pas beaucoup de sens pour nous, mais juste au cas où, il est préférable de le désactiver.
Connectez-vous via SSH à notre instance. Si vous utilisez un client graphique SSH, par exemple, PuTTY, pour vous connecter, l'aide intégrée sur la connexion, appelée par RMB sur l'instance -> Connect, vous aidera:
Amazon Linux conserve un pedigree de RHEL et CentOS, donc le gestionnaire de packages yum est utilisé.
Toutes les opérations décrites ci-dessous doivent être effectuées avec une élévation de privilèges, nous les précédons donc avec sudo ou travaillons simplement en tant que root.
Première mise à jour:
En tant que logiciel pour organiser un serveur VPN, nous utiliserons une combinaison de libreswan et xl2tpd.
LibreSwan (fork d'OpenSwan et un analogue de strongSwan) est une implémentation populaire de VPN IPSec et IKE (Internet Key Exchange). Il peut contourner correctement différents types de NAT et leurs combinaisons, ce qui est particulièrement important lors de l'organisation du tunneling IPSec.
xl2tpd est également largement utilisé, son principal avantage est la capacité intégrée d'authentifier et de transmettre les paramètres de connexion client via ppp lors de la connexion (par exemple, adresses IP, paramètres de route par défaut, serveurs DNS, etc.), ce qui élimine la nécessité d'un déploiement DHCP et Radius supplémentaire pour notre tâches simples.
Étant donné que xl2tpd n'est pas dans les référentiels Amazon Linux standard, nous devons activer EPEL (Extra Packages for Enterprise Linux):
Installez les packages nécessaires:
Activer le routage au niveau du noyau:
dans le fichier
/etc/sysctl.conf on Ă©crit:
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
DĂ©sactivez
rp_filter dans la session en cours pour ne pas redémarrer:
Nous appliquons les paramètres et vérifions la disponibilité du routage:
Nous devons assurer la transmission des paquets entrants (par rapport à l'interface publique de l'instance) des ports des services requis vers notre futur tunnel IPSec. Pour cela, il faut non seulement dé-NAT ces paquets, mais aussi faire du masquage sur l'interface
ppp0 .
Nous utiliserons pour cela les fonctionnalités
iptables intégrées, qui dans le cas d'Amazon Linux sont initialement configurées pour autoriser complètement tout trafic dans n'importe quelle direction:
faire DNAT des ports requis:
transmettre tous les paquets qui sont arrivés à ces ports à l'adresse de la porte Windows:
faire du masquage pour ces packages:
Il est conseillé de conserver les règles iptables afin qu'elles se resserrent automatiquement au redémarrage de l'instance:
Dans ce cas, nous utilisons le DNAT (Destination NAT) du port TCP requis à partir de l'interface réseau eth0 de l'instance en direction de l'adresse IPv4 10.100.0.2, qui est l'adresse sur l'interface ppp du service RRAS de notre porte Windows dans l'hyperviseur domestique.
Le point suivant est très important: puisque les services à l'intérieur de l'hyperviseur doivent pouvoir répondre aux demandes reçues de l'instance AWS, il est nécessaire de fournir un masquage (remplacement de l'adresse de l'expéditeur) sur l'interface
ppp0 de l'instance avant d'envoyer le paquet, sinon la réponse ira dans une direction complètement différente: de la porte Windows dans l'hyperviseur après le tunnel IPSec directement vers le routeur par défaut (routeur domestique), à ​​la suite de quoi, bien sûr, il sera supprimé du côté client du service, comme s'il provenait d'une ressource non sollicitée. Si le masquage est utilisé dans l'en-tête du paquet à l'entrée du tunnel vpn, l'adresse de l'expéditeur passera de l'adresse quelque part sur Internet à l'adresse
ppp0 de l' interface de l'instance AWS: EC2, c'est-Ă -dire dans mon cas Ă 10.100.0.1
Au lieu d'utiliser iptables pour d'autres distributions Linux ou systèmes * NIX, vous pouvez recommander le bon vieux rinetd, où tout cela se fait généralement sur une seule ligne dans sa configuration
rinetd.conf :
<ip source> <port source> <ip destination> <port destination>
La seule chose qui devra être activée dans ce cas dans le noyau est la possibilité de routage / trafic NAT.
Il est temps de cuisiner libreswan.
Le fichier
/etc/ipsec.conf contient des instructions pour télécharger tous les fichiers .conf depuis /etc/ipsec.d/, par conséquent, nous créons un nouveau fichier de configuration dans le répertoire /etc/ipsec.d/aws_vpn.conf et nous y ajoutons:
config setup
Pour plus de simplicité, nous utiliserons l'authentification IPSec basée sur une clé partagée (PSK), et non sur des certificats, nous devons donc la spécifier explicitement. Le fichier
/etc/ipsec.secrets contient des instructions pour télécharger tous les fichiers .secrets de
/etc/ipsec.d/ , là nous créons un nouveau fichier
/etc/ipsec.d/aws_vpn.secrets et
spécifions le PSK dans le format:
< 172...> %any : PSK "< PSK>"
A titre d'exemple:
172.31.20.120 %any : PSK "Pa$$w0rd"
Étant donné que la connexion ppp sera utilisée à l'intérieur du tunnel IPSec et qu'il existe sa propre authentification, nous la configurons également:
Nous entrons le nom d'utilisateur et le mot de passe dans le fichier
/ etc / ppp / chap-secrets au format:
<user> * <password> *
A titre d'exemple:
aws_user * Pa$$w0rd *
Lors de la connexion au client ppp, il est possible de passer un certain nombre d'options pour configurer l'interface réseau et la table de routage de sa part.
Dans le fichier
/etc/ppp/options.xl2tpd , définissez ces options:
Parce que nous n'avons pas besoin de transmettre les adresses DNS, victoires, etc. au client. choses - toutes les autres options doivent être commentées.
Ici, vous avez besoin d'une explication de la configuration.
Le comportement standard pour les connexions VPN consiste à installer une nouvelle route par défaut dans la table client, ce qui force tout le trafic de celle-ci vers Internet à «passer» par le serveur VPN. Dans notre cas, c'est faux, car l'objectif de la porte Windows est de fournir un accès simulé à Internet du réseau de bureaux virtuels derrière lui dans l'hyperviseur et de publier les ressources des services internes vers l'extérieur via AWS: EC2, il est donc irrationnel de diriger tout le trafic via l'instance vers AWS: EC2. C'est pourquoi vous devez empêcher une connexion VPN dans RRAS de modifier l'itinéraire par défaut (vers un routeur domestique).
Il est également important de choisir les valeurs MTU et MRU correctes: nous utilisons le tunneling IPSec et une taille de charge utile trop grande peut ne pas correspondre à la limite d'encapsulation, ce qui entraînera une fragmentation et très probablement une erreur. S'il apparaît, essayez tout d'abord de réduire ces valeurs, par exemple, à 1280. Les valeurs indiquées dans la configuration donnée sont compatibles avec le client VPN Windows.
Reste Ă configurer xl2tpd
Nous configurons tout ce qui est nécessaire dans le fichier de configuration 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
Nous vérifions tout ce que nous avons fait
Nous essayons d'exécuter les deux services et vérifions les configurations:
service ipsec start service xl2tpd start ipsec verify
Les services sont peut-être déjà en cours d'exécution, auquel cas ils sont simplement redémarrés.
Si tout va bien, la sortie de ipsec verify devrait ĂŞtre similaire Ă la capture d'Ă©cran:
Vous pouvez déboguer xl2tpd de manière interactive en l'exécutant avec le commutateur -D et en le suspendant dans une «fenêtre» distincte du terminal SSH à l'aide de l'utilitaire
screen :
Dans ce cas, le processus xl2tpd ne passera pas en arrière-plan, mais affichera toutes ses activités sur l'écran du terminal.
En cas de problème, vous devez décommenter les options de débogage dans les configurations (voir les commentaires) et consulter le contenu des journaux système et du fichier
/var/log/pluto.log . Il convient Ă©galement de prĂŞter attention au contenu de l'
option virtual_private / virtual-private dans le fichier
/etc/ipsec.conf , il répertorie tous les réseaux privés disponibles pour l'échange de données via IPSec. Si, pour une raison quelconque, vous avez votre propre adressage, par exemple, vous utilisez votre propre pool d'adresses IPv4 blanches, vous devez apporter des modifications à ce paramètre.
Passons à la dernière étape - configurer le service RRAS dans la porte Windows et vérifier la publication des services à partir d'Internet
Il est supposé que votre hyperviseur domestique dispose d'une machine virtuelle exécutant Windows 2012R2 ou plus récente, déployée en mode graphique (bureau), et il y a deux adaptateurs réseau dans cette machine virtuelle: l'un "regarde" dans le réseau domestique et a un routeur domestique comme route par défaut et l'autre dans un réseau de «bureaux» local virtuel, dans lequel des services sont publiés à l'extérieur. Un domaine Windows est facultatif, à moins bien sûr que les services eux-mêmes ne l'exigent.
Nous installons tous les rôles nécessaires à l'aide du Gestionnaire de serveur ou à l'aide de l'applet de commande PowerShell
Install-WindowsFeature :
Ici, je démontre l'installation de rôles via des graphiques, car il sera alors beaucoup plus pratique d'appeler l'assistant de configuration à partir du Gestionnaire de serveur et de configurer le service RRAS lui-même dans le calendrier, ce qui nous plaira avec la bonne vieille interface de l'époque de Windows Server 2003:
Cliquez sur RMB sur votre serveur, sélectionnez
«Configurer et activer le routage et l'accès distant» , puis configurez manuellement:
N'hésitez pas à sélectionner tous les choucas, à terminer l'assistant et à démarrer le service:
Tout d'abord, libérons notre réseau local virtuel à l'extérieur. Nous allons à IPv4-> NAT et créons une nouvelle interface, comme l'interface existante sur laquelle NAT sera implémenté, sélectionnez l'interface externe (qui regarde sur Internet, ou plutôt dans votre réseau domestique), marquez-la comme publique et activez NAT dessus:
Nous vérifions comment le trafic du LAN virtuel sort par notre portail. Nous n'avons pas encore besoin de configurer le pare-feu Windows.
Si tout va bien, nous allons enfin crĂ©er ce pour quoi nous nous battions, une connexion VPN Ă notre instance AWS et vĂ©rifier la publication de nos services. Nous allons dans le composant logiciel enfichable RRAS Ă
«Interfaces réseau» et créons une nouvelle interface de numérotation à la demande avec un nom arbitraire:
Sélectionnez immédiatement la connexion L2TP, afin que notre nouvelle interface n'essaie pas automatiquement de déterminer le type de VPN et, par conséquent, qu'elle se connecte plus rapidement:
Plus loin dans l'assistant, nous indiquons l'adresse publique de notre cloud (dans mon cas, Elastic IP). Dans les Ă©tapes suivantes, laissez tout tel quel, car nous n'avons pas besoin d'une connexion de site Ă site:
Spécifiez le compte utilisateur sous lequel nous avons configuré la connexion ppp (dans le fichier
/ etc / ppp / chap-secrets ). Aucun nom de domaine n'est requis:
L'assistant crée une nouvelle connexion. Reste maintenant à le configurer. Nous allons ajuster le délai d'inactivité (Idle-time), supprimer le CHAP obsolète au profit de MS-CHAPv2 uniquement, spécifier la clé PSK dans les «Propriétés avancées» (celle qui a été définie pour xl2tpd dans le fichier /etc/ipsec.d/aws_vpn. secrets) et supprimez IPv6:
Après avoir créé une nouvelle interface, vous devez également entrer dans les propriétés du service RRAS lui-même, activer votre stratégie IPSec pour L2TP et spécifier votre PSK. Il leur est demandé de redémarrer le service RRAS.
Il semblerait que tout peut être soulevé en toute sécurité une nouvelle interface et profiter du travail. Mais non. Étant donné que nous avons utilisé NAT du côté de l'instance AWS: EC2, le client VPN Windows ne pourra pas se connecter à un tel nœud Nat-Traversal. Cela est vrai à la fois pour les versions client (jusqu'à la dernière au moment de la rédaction de cet article de la version Windows 10) et pour les serveurs.
Heureusement, il existe une solution officielle à ce problème sous la forme de modifications dans le registre des paramètres du service de stratégie IPSec suivies d'un redémarrage:
Ă€
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgentcréer une clé DWORD (32 bits)
SupposonsUDPEncapsulationContextOnSendRule = 2et redémarrez notre Windows Gate.
Le service RRAS est malheureusement célèbre pour son caractère capricieux dans la configuration et le fonctionnement, et même après un redémarrage, il effectue un démarrage différé. Vous pouvez donc vous précipiter après un redémarrage.
Si tout est fait correctement, la connexion fonctionnera dans les 5 Ă 10 secondes.
Reste à faire la publication des ressources nécessaires sur le portail Windows lui-même.
Pour le test nous travaillerons sur la publication du serveur web. Tout d'abord, consultez notre tunnel IPSec et les règles iptables.
Avec des mains tremblantes, nous vérifions à partir d'un PC arbitraire connecté à Internet:
Wow, ça marche ...
Lors de l'installation des rôles nécessaires, le MS IIS «natif» a été installé de force, mais nous le voulons encore plus facilement. Pour cela, sur une plateforme Windows,
HFS (HTTP File Server) est bien adapté - il est gratuit, ne nécessite pas d'installation, donne une page spécifique et un en-tête HTTP, peut fonctionner sur un port arbitraire (par défaut c'est 8080, donc dans notre cas il faudra reconfigurer en 80), et écrit également immédiatement dans sa console d'où provient la connexion, ce qui est très pratique pour déboguer la publication de nombreuses ressources Web sur la plate-forme Windows. Pour l'utiliser, vous devez d'abord arrêter le site MS IIS afin de délier le serveur intégré du port requis. Étant donné que nous ne voulons pas installer la console de gestion MS IIS (en fait, la console MS IIS 6 sera présente pour des raisons de compatibilité, mais IIS 7+ ne peut pas être contrôlé via elle), nous le ferons via PowerShell:
Stop-WebSite -Name "Default Web Site"
ou simplement via l'utilitaire de gestion iisreset:
iisreset /stop
Après cela, vous devez autoriser le trafic entrant vers le port 80 dans le pare-feu Windows intégré.
Nous démarrons HFS et vérifions:
Tout est super. Nous avons réalisé que de n'importe où sur Internet, vous pouvez voir le serveur Web qui vit dans notre maison comme une machine virtuelle dans un hyperviseur arbitraire.
La touche finale: nous apprenons à RRAS à transmettre toutes ces demandes de l'extérieur vers le réseau du bureau virtuel, où, selon la légende, nous avons un autre serveur Web.
Pour ce faire, nous allons à nouveau dans le composant logiciel enfichable de gestion RRAS dans IPv4-> NAT et RMB sur notre interface VPN, où nous sélectionnons l'onglet
«Services et ports» , le marquons dans la liste des serveurs Web et spécifions le serveur Web dans le réseau virtuel interne dont nous voulons publier les ressources. internet:
Cliquez sur OK et ... tout est prêt. Nous vérifions - tout devrait bien fonctionner.
D'une manière si simple, vous pouvez publier rapidement presque tous les services et ressources, des sites, des serveurs de messagerie à certaines intégrations complexes. Naturellement, pour la plupart d'entre eux, vous aurez besoin d'avoir votre propre domaine DNS avec la possibilité de créer des sous-domaines et de modifier les enregistrements nécessaires. Il est également conseillé d'utiliser des certificats SSL pour publier des ressources Web,
grâce à LetsEncrypt et à des services similaires compatibles ACME, tout cela peut être fait entièrement gratuitement et avec une mise à jour automatique.
Lorsque vous redémarrez l'instance, l'adresse IPv4 publique ne change pas - uniquement lorsqu'elle est arrêtée, mais il est toujours recommandé d'utiliser une adresse IPv4 statique dans AWS: EC2. Statique dans le sens où lorsque vous désactivez votre instance, elle lui reste affectée et ne tombe pas dans le pool libre général. Bien sûr, cela est nécessaire pour ne pas s'embêter à chaque fois avec la reconfiguration des enregistrements DNS dans les domaines, et personne n'a annulé TTL avec mise en cache. Cela coûte beaucoup d'argent et s'appelle, comme déjà mentionné ci-dessus,
Elastic IP .
Automatisation primitive des processus
Enfin, je veux mentionner une autre grande fonctionnalité d'AWS: EC2 - configuration rapide de l'instance déployable. Il existe de nombreuses options de déploiement rapide dans AWS: EC2, jusqu'à des services spéciaux (et plutôt complexes, mais très puissants), mais il y a la plus simple: à l'étape 3 de l'assistant de création d'une nouvelle instance en bas se trouve le champ
"Données utilisateur" . Vous pouvez y placer un script en bash ou même PowerShell (dans le cas d'une instance pour Windows), et ce script sera exécuté automatiquement immédiatement après la création de l'instance.
C'est-à -dire vous pouvez légèrement modifier toutes les commandes et configurations ci-dessus pour créer votre propre script bash et l'utiliser pour augmenter rapidement un tel routeur AWS: EC2 virtuel.
En savoir plus sur cette fonctionnalité .
Merci d'avoir pris le temps de lire cet article.