L’auteur a sélectionné le Open Internet / Free Speech Fund pour recevoir un don dans le cadre du https://do.co/w4do-cta Programme [Write for DOnations] .
introduction
Les réseaux privés fournissent généralement un accès Internet aux hôtes à l’aide de NAT (traduction d’adresse réseau), en partageant une adresse IP publique unique avec tous les hôtes du réseau privé. Dans les systèmes NAT, les hôtes du réseau privé ne sont pas visibles de l’extérieur du réseau. Pour exposer les services exécutés sur ces hôtes sur Internet, vous devez généralement créer des règles NAT dans la passerelle, appelées généralement règles de transfert de port. Cependant, dans plusieurs situations, vous n’auriez pas accès à la passerelle pour configurer ces règles. Pour des situations telles que celle-ci, les solutions de tunneling telles que PageKite sont pratiques.
http://pagekite.net [PageKite] est une solution de tunneling rapide et sécurisée qui permet d’exposer un service situé sur un réseau privé à l’internet public sans nécessiter de redirection de port. Pour ce faire, il s’appuie sur un serveur externe, appelé serveur frontal, auquel le serveur situé derrière NAT et les clients se connectent pour permettre la communication entre eux. Par défaut, PageKite utilise son propre service commercial http://pagekite.net [pagekite.net], mais comme il s’agit d’un projet entièrement à source ouverte, il vous permet de configurer une interface privée sur un hôte accessible au public, tel que un DigitalOcean Droplet. Avec cette configuration, vous pouvez créer une solution indépendante du fournisseur pour un accès à distance aux hôtes situés derrière NAT. En configurant les hôtes distants avec le client PageKite pour qu’ils se connectent à l’interface et exposent le port SSH, il est possible d’y accéder via le shell d’interface de ligne de commande à l’aide de SSH. Il est également possible d’accéder à une interface utilisateur graphique à l’aide d’un système de partage de bureau tel que VNC ou RDP running sur une connexion SSH.
Dans ce tutoriel, vous allez installer et configurer un service frontal PageKite sur un serveur exécutant Debian 9. Vous allez également configurer deux autres serveurs Debian 9 pour simuler un environnement local et un environnement distant. Lorsque vous aurez terminé, vous aurez configuré un serveur pour plusieurs clients et l’avez testé avec une solution pratique pour l’accès à distance à l’aide de SSH et de VNC.
Conditions préalables
Avant de suivre ce guide, vous aurez besoin des éléments suivants:
-
Un compte DigitalOcean pour configurer les gouttelettes qui seront utilisées dans le didacticiel.
-
Un serveur exécutant Debian 9 avec une adresse IP publique servant de serveur frontal, configuré conformément à la procédure https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-9 [ Configuration initiale du serveur avec Debian 9]. Un droplet DigitalOcean standard avec 1 Go de mémoire suffit à des fins de test ou pour des applications nécessitant peu de connexions. Nous ferons référence à ce serveur par le nom d’hôte
+ serveur frontal + +et son adresse IP publique par++. -
Deux hôtes exécutant Debian 9, qui joueront le rôle d’hôte distant et local et qui se connecteront à l’aide du service PageKite, configurés conformément à la https://www.digitalocean.com/community/tutorials/initial-server-setup- with-debian-9 Guide [Configuration initiale du serveur avec Debian 9]. L’hôte local utilisera un tunnel PageKite pour accéder à l’hôte distant, avec un accès Internet via NAT. Les hôtes locaux et distants seront désignés par les noms d’hôte
+ hôte-distant +et+ hôte-local +et leurs adresses IP publiques par` et `respectivement. Ce didacticiel utilisera deux droplets DigitalOcean standard avec 1 Go de mémoire pour les représenter. Vous pouvez également utiliser deux machines locales ou virtuelles pour représenter ces hôtes. -
Un nom de domaine entièrement enregistré. Ce tutoriel utilisera
++comme exemple. Vous pouvez acheter un nom de domaine sur https://namecheap.com [Namecheap], en obtenir un gratuitement sur Freenom ou utiliser le registraire de domaine de votre choix. . -
Les deux enregistrements DNS suivants sont configurés pour votre serveur. Vous pouvez suivre this introduction to DigitalOcean DNS pour savoir comment les ajouter.
-
Un enregistrement A avec
+ pagekite. +Pointant sur l’adresse IP du `+ serveur frontal + +. -
Nous devons également configurer DNS afin que chaque domaine se terminant par
+ pagekite. +Indique également notre serveur+ serveur frontal +. Cela peut être configuré à l’aide d’entrées DNS génériques. Dans ce cas, créez un enregistrement A pour l’entrée DNS générique+ *. Pagekite. +Pour indiquer la même adresse IP,++. Cela servira à distinguer les clients qui se connectent à notre serveur par nom de domaine (+ client-1.pagekite. +Et+ client-2.pagekite. +, Par exemple) et à canaliser correctement les demandes de personnel. -
Un ordinateur local avec un client VNC installé qui prend en charge les connexions VNC sur des tunnels SSH.
-
Sous Windows, vous pouvez utiliser TightVNC, RealVNC ou UltraVNC.
-
Sur macOS, vous pouvez utiliser le programme intégré Screen Sharing ou utiliser une application multiplate-forme, telle que RealVNC.
-
Sous Linux, vous pouvez choisir parmi de nombreuses options, notamment https://wiki.gnome.org/Apps/Vinagre [
+ vinagre +], https://kde.org/applications/internet/org.kde.krdc [` + krdc + `], RealVNC ou TightVNC.
Étape 1 - Configuration des serveurs
Dans ce didacticiel, nous allons utiliser trois droplets DigitalOcean pour jouer le rôle de + serveur frontal , ` hôte local , et` + hôte distant + `. Pour ce faire, nous allons d’abord paramétrer le ` local-host ` et le + + remote-host + `à accéder à l’environnement graphique et à imiter le comportement d’un` + remote-host + `sous NAT, de sorte que PageKite puisse être utilisé comme une solution pour accéder à ses services. En outre, nous devons également configurer les règles de pare-feu Droplet ` serveur frontal ` afin de lui permettre de fonctionner avec PageKite et d’interfacer la connexion entre ` local-host ` et ` remote-host +`.
Comme nous allons utiliser plusieurs serveurs, nous allons utiliser différentes couleurs dans les listes de commandes pour identifier le serveur que nous utilisons, comme suit:
# Commands and outputs in the front-end-server Droplet# Commands and outputs in the remote-host Droplet# Commands and outputs in the local-host Droplet# Commands and outputs in both the remote-host and local-host DropletsCommençons par les étapes des droplets + remote-host + + et + local-host + , pour installer les dépendances et configurer l’accès à l’environnement graphique à l’aide de VNC. Après cela, nous couvrirons la configuration du pare-feu dans chacune des trois droplets pour permettre au `+ serveur frontal + de lancer PageKite et d’imiter une connexion utilisant NAT sous + hôte distant +.
Installation de dépendances
Nous aurons besoin d’accéder à l’interface graphique sur les hôtes + local-host et` + remote-host ou` pour exécuter cette démonstration. Sur + local-host +, nous utiliserons une session VNC pour accéder à son interface graphique et tester notre configuration à l’aide du navigateur. Sur + remote-host +, nous allons configurer une session VNC à laquelle nous accéderons à partir de + local-host +.
Pour configurer VNC, nous devons d’abord installer certaines dépendances sur + local-host + et + remote-host +. Mais avant d’installer un paquet, nous devons mettre à jour la liste des paquets des référentiels, en exécutant ce qui suit sur les deux serveurs:
sudo apt-get updateEnsuite, nous installons le serveur VNC et un environnement utilisateur graphique, nécessaires pour démarrer une session VNC. Nous utiliserons le serveur Tight VNC et l’environnement de bureau Xfce, qui peuvent être installés en exécutant:
sudo apt-get install xfce4 xfce4-goodies tightvncserverAu milieu de l’installation de l’environnement graphique, nous serons interrogés sur la disposition du clavier que nous souhaitons utiliser. Pour un clavier QWERTY US, sélectionnez + English (US) +.
En plus de cela, sur + local-host + , nous aurons besoin d’un visualiseur VNC et d’un navigateur Internet pour pouvoir établir la connexion avec + remote-host + `. Ce tutoriel installe le navigateur Web Firefox et le xtightvncviewer. Pour les installer, lancez:
sudo apt-get install firefox-esr xtightvncviewerLorsqu’un environnement graphique est installé, le système s’initialise en mode graphique par défaut. En utilisant la console DigitalOcean, il est possible de visualiser le gestionnaire de connexion graphique, mais il n’est pas possible de se connecter ou d’utiliser l’interface de ligne de commande. Dans notre configuration, nous imitons le comportement du réseau comme si nous utilisions NAT. Pour ce faire, nous devrons utiliser la console DigitalOcean, car nous ne pourrons pas nous connecter via SSH. Par conséquent, nous devons désactiver l’interface utilisateur graphique à partir du démarrage automatique au démarrage. Cela peut être fait en désactivant le gestionnaire de connexion sur les deux serveurs:
sudo systemctl disable lightdm.serviceAprès avoir désactivé le gestionnaire de connexion, nous pouvons redémarrer les Droplets et vérifier si nous pouvons nous connecter à l’aide de la console DigitalOcean. Pour ce faire, exécutez ce qui suit:
sudo shutdown -r nowEnsuite, accédez à la console DigitalOcean en accédant à la page Droplet dans le panneau de configuration DigitalOcean, en sélectionnant votre droplet + local-host +, puis en cliquant sur le mot * Console * dans le coin supérieur droit, près du commutateur, pour activer le droplet. Et hors:
image: https: //assets.digitalocean.com/articles/cart-64916/DigitalOcean_Control_Panel.png [Panneau de configuration DigitalOcean]
Une fois que vous avez appuyé sur Entrée dans la console, votre nom d’utilisateur et votre mot de passe vous seront demandés. Entrez ces informations d’identification pour afficher l’invite de ligne de commande:
image: https: //assets.digitalocean.com/articles/cart-64916/DigitalOcean_Droplet_Console.jpg [Console pour les gouttelettes DigitalOcean]
Une fois que vous avez fait cela pour le + local-host on, répétez pour le` + remote-host`.
Avec la console mise en place pour les deux Droplets, nous pouvons maintenant configurer le VNC.
Configuration de VNC
Ici, nous allons mettre en place une configuration de base VNC. Si vous souhaitez un guide plus détaillé sur la manière de procéder, consultez notre https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-debian- 9 Didacticiel [Comment installer et configurer VNC sur Debian 9].
Pour démarrer une session VNC, exécutez les opérations suivantes sur les deux Droplets + local-host et` + remote-host`:
vncserverLors de la première exécution, le système créera les fichiers de configuration et demandera le mot de passe principal. Entrez votre mot de passe souhaité, puis vérifiez-le. Le serveur VNC demandera également un mot de passe en lecture seule, utilisé pour afficher la session VNC d’un autre utilisateur. Comme nous n’aurons pas besoin d’une session VNC en lecture seule, tapez + n + pour cette invite.
La sortie ressemblera à ceci:
Output@:/home/$ vncserver
You will require a password to access your desktops.
Password:
Verify:
Would you like to enter a view-only password (y/n)? n
xauth: file /home//.Xauthority does not exist
New 'X' desktop is remote-host:1
Creating default startup script /home//.vnc/xstartup
Starting applications specified in /home//.vnc/xstartup
Log file is /home//.vnc/:1.logLe +: 1 + après le nom d’hôte représente le numéro de la session VNC. Par défaut, le numéro de session + 1 + est exécuté sur le port + 5901 +, le numéro de session + 2 + sur le port + 5902 +, etc. Après la sortie précédente, nous pouvons accéder à + remote-host + en utilisant un client VNC pour se connecter à ++ sur le port + 5901 +.
L’un des problèmes de la configuration précédente est qu’elle n’est pas persistante, ce qui signifie qu’elle ne sera pas démarrée par défaut lors du redémarrage de Droplet. Pour le rendre persistant, nous pouvons créer un service Systemd et l’activer. Pour ce faire, nous allons créer le fichier + vncserver @ .service + sous + / etc / systemd / system +, ce qui peut être fait en utilisant + nano +:
sudo nano /etc/systemd/system/[email protected]Placez le contenu suivant dans le fichier, en remplaçant "++" par votre nom d’utilisateur:
/etc/systemd/system/[email protected]
[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target
[Service]
Type=forking
User=
PAMName=login
PIDFile=/home//.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i
[Install]
WantedBy=multi-user.targetCe fichier crée une unité + vncserver + Systemd, qui peut être configurée en tant que service système à l’aide de l’outil + systemctl +. Dans ce cas, lorsque le service est démarré, il tue la session VNC si elle est déjà en cours d’exécution (ligne + ExecStartPre +) et démarre une nouvelle session en utilisant la résolution définie sur + 1280x800 + (ligne + ExecStart +). Lorsque le service est arrêté, la session VNC est supprimée (ligne + ExecStop +).
Enregistrez le fichier et quittez + nano +. Ensuite, nous informerons le système du nouveau fichier d’unité en exécutant:
sudo systemctl daemon-reloadEnsuite, activez le démarrage automatique du service lors de l’initialisation du serveur en exécutant:
sudo systemctl enable [email protected]Lorsque nous utilisons la commande + enable + avec + systemctl +, des liens symboliques sont créés pour que le service soit lancé automatiquement à l’initialisation du système, comme indiqué par le résultat de la commande précédente:
OutputCreated symlink /etc/systemd/system/multi-user.target.wants/[email protected] → /etc/systemd/system/[email protected].Avec le serveur VNC correctement configuré, nous pouvons redémarrer les Droplets pour vérifier si le service est démarré automatiquement:
sudo shutdown -r nowUne fois le système initialisé, connectez-vous à l’aide de SSH et vérifiez si VNC s’exécute avec:
sudo systemctl status [email protected]La sortie indiquera que le service est en cours d’exécution:
● [email protected] - Start TightVNC server at startup
Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: since Thu 2019-08-29 19:21:12 UTC; 1h 22min ago
Process: 848 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :1 (code=exited, status=0/SUCCESS)
Process: 760 ExecStartPre=/usr/bin/vncserver -kill :1 > /dev/null 2>&1 (code=exited, status=2)
Main PID: 874 (Xtightvnc)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/system-vncserver.slice/[email protected]
‣ 874 Xtightvnc :1 -desktop X -auth /home/sammy/.Xauthority -geometry 1280x800 -depth 24 -rfbwait
Aug 29 19:21:10 remote-host systemd[1]: Starting Start TightVNC server at startup...
Aug 29 19:21:10 remote-host systemd[760]: pam_unix(login:session): session opened for user sammy by (uid=0)
Aug 29 19:21:11 remote-host systemd[848]: pam_unix(login:session): session opened for user sammy by (uid=0)
Aug 29 19:21:12 remote-host systemd[1]: Started Start TightVNC server at startup.
~Ceci termine la configuration de VNC. N’oubliez pas de suivre les étapes précédentes sur + remote-host + et + local-host +. Voyons maintenant les configurations de pare-feu pour chaque hôte.
Configuration du pare-feu
En commençant par + remote-host +, nous allons configurer le pare-feu pour qu’il interdise les connexions externes aux services des gouttelettes afin d’imiter le comportement derrière le NAT. Dans ce tutoriel, nous allons utiliser le port + 8000 + pour les connexions HTTP, + 22 + pour SSH et + 5901 + pour VNC. Nous allons donc configurer le pare-feu pour refuser les connexions externes à ces ports.
En suivant la configuration initiale de pour Debian 9, + remote-host + aura une règle de pare-feu permettant les connexions. à SSH. Nous pouvons revoir cette règle en lançant:
sudo ufw status verboseLa sortie sera la suivante:
OutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)Supprimez ces règles SSH pour imiter le comportement derrière NAT.
Pour refuser l’accès SSH, utilisez + ufw + et exécutez:
sudo ufw delete allow OpenSSHNous pouvons vérifier que les règles SSH ont été supprimées en vérifiant à nouveau l’état du pare-feu:
sudo ufw status verboseLa sortie ne montrera aucune règle de pare-feu, comme dans ce qui suit:
OutputStatus: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skipBien que le pare-feu soit configuré, la nouvelle configuration ne fonctionne pas tant que nous ne l’activons pas avec:
sudo ufw enableAprès l’avoir activé, notez que nous ne pourrons plus accéder à + remote-host via SSH, comme indiqué dans le résultat de la commande:
OutputCommand may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startupDéconnectez-vous du + remote-host +, puis testez la configuration en essayant d’établir une connexion SSH ou VNC. Ce ne sera pas possible. A partir de maintenant, nous pouvons accéder à + remote-host + exclusivement par la console DigitalOcean.
Sur + local-host +, nous allons laisser les ports SSH ouverts. Une seule règle de pare-feu est nécessaire pour autoriser l’accès à la session VNC:
sudo ufw allow 5901Après avoir modifié les règles du pare-feu, activez-le en lançant:
sudo ufw enableNous pouvons maintenant tester la connexion VNC en utilisant les https://www.digitalocean.com/community/tutorials/how-to-set-up-a-pagekite-front-end-server-on-a-debian-9# [client VNC prérequis sur votre ordinateur local] pour vous connecter à + local-host + 'sur le port + 5901 + `en utilisant le mot de passe VNC que vous avez configuré.
Pour ce faire, ouvrez votre client VNC et connectez-vous à +: 5901 +. Une fois le mot de passe saisi, vous vous connecterez à la session VNC.
Lors de son premier démarrage, Xfce posera des questions sur la configuration initiale de l’environnement:
image: https: //assets.digitalocean.com/articles/cart-64916/Initial_Xfce_Configuration.png [Configuration Xfce initiale]
Pour ce tutoriel, sélectionnez l’option * Use default config *.
Enfin, nous devons autoriser les connexions au port + 80 + sur le + serveur frontal +, qui sera utilisé par PageKite. Ouvrez un terminal sur + serveur frontal + et utilisez la commande suivante:
sudo ufw allow 80De plus, autorisez le trafic sur le port + 443 + pour HTTPS:
sudo ufw allow 443Pour activer la nouvelle configuration du pare-feu, exécutez les opérations suivantes:
sudo ufw enableMaintenant que nous avons configuré les Droplets, configurons le serveur frontal PageKite.
Étape 2 - Installation de PageKite sur le serveur frontal
Bien qu’il soit possible d’exécuter PageKite à l’aide d’un script Python pour configurer le serveur frontal, il est plus fiable de l’exécuter à l’aide d’un service système. Pour ce faire, nous devrons installer PageKite sur le serveur.
La méthode recommandée pour installer un service sur un serveur Debian consiste à utiliser un paquet distribution. De cette façon, il est possible d’obtenir des mises à jour automatisées et de configurer le service pour qu’il démarre au démarrage.
Tout d’abord, nous allons configurer le référentiel pour installer PageKite. Pour ce faire, mettez à jour la liste des packages des référentiels:
sudo apt-get updateUne fois la mise à jour terminée, installez le paquet https://packages.debian.org/stretch/dirmngr [+ dirmngr +], qui est nécessaire pour prendre en charge l’importation de clés dans le référentiel PageKite pour garantir une installation sécurisée:
sudo apt-get install dirmngrEnsuite, ajoutez le référentiel au fichier + / etc / apt / sources.list en lançant:
echo deb http://pagekite.net/pk/deb/ pagekite main | sudo tee -a /etc/apt/sources.listAprès avoir configuré le référentiel, importez la clé de package PageKite dans notre ensemble de clés approuvé, afin que nous puissions installer des packages à partir de ce référentiel. La gestion des clés d’empaquetage est effectuée à l’aide de l’utilitaire + apt-key +. Dans ce cas, nous devons importer la clé + AED248B1C7B2CAC3 + à partir du serveur de clés + keys.gnupg.net +, ce qui peut être fait en exécutant:
sudo apt-key adv --recv-keys --keyserver keys.gnupg.net AED248B1C7B2CAC3Ensuite, mettez à jour à nouveau les listes de paquets des référentiels, de sorte que le paquet + pagekite + soit indexé:
sudo apt-get updateEnfin, installez-le avec:
sudo apt-get install pagekiteMaintenant que PageKite est installé, configurons le serveur frontal et le service pour qu’il s’exécute au démarrage.
Étape 3 - Configuration du serveur frontal
Le package PageKite que nous venons d’installer peut être utilisé pour configurer une connexion à un serveur frontal PageKite. Il peut également être utilisé pour configurer un service frontal afin de recevoir des connexions PageKite, ce que nous souhaitons faire ici. Pour ce faire, nous devons éditer les fichiers de configuration de PageKite.
PageKite stocke ses fichiers de configuration dans le répertoire + / etc / pagekite.d +. Le premier changement que nous devons faire est de désactiver toutes les lignes du fichier + / etc / pagekite.d / 10_account.rc +, car ce fichier n’est utilisé que lorsque PageKite est configuré en tant que client pour se connecter à un serveur frontal. . Nous pouvons éditer le fichier en utilisant + nano +:
sudo nano /etc/pagekite.d/10_account.rcPour désactiver les lignes, ajoutez un + # + pour désactiver les lignes actives du fichier:
/etc/pagekite.d/10_account.rc
#################################[ This file is placed in the Public Domain. ]#
# Replace the following with your account details.
kitename = NAME.pagekite.me
kitesecret = YOURSECRET
# Delete this line!
abort_not_configuredAprès avoir effectué les modifications, sauvegardez-les et quittez + nano +. Ensuite, éditez le fichier + / etc / pagekite.d / 20_frontends.rc +:
sudo nano /etc/pagekite.d/20_frontends.rcAjoutez les lignes en surbrillance suivantes au fichier et commentez la ligne + defaults +, en veillant à remplacer ` par le nom de domaine que vous utilisez et ` par un mot de passe de votre choix:
/etc/pagekite.d/20_frontends.rc
#################################[ This file is placed in the Public Domain. ]#
# Front-end selection
#
# Front-ends accept incoming requests on your behalf and forward them to
# your PageKite, which in turn forwards them to the actual server. You
# probably need at least one, the service defaults will choose one for you.
# Use the pagekite.net service defaults.
defaults
# If you want to use your own, use something like:
# frontend = hostname:port
# or:
# frontends = COUNT:dnsname:portExpliquons ces lignes une par une. Premièrement, pour configurer PageKite en tant que serveur frontal, nous avons ajouté la ligne + isfrontend +. Pour configurer les ports sur lesquels le serveur va écouter, nous avons ajouté + ports = 80,443 +. Nous avons également configuré les protocoles que PageKite va utiliser comme proxy. Pour utiliser HTTP, HTTPS et RAW (utilisé par les connexions SSH), nous ajoutons la ligne + protos = http, https, raw +. Nous désactivons également les paramètres + defaults + afin qu’il n’y ait pas de configuration en conflit pour le serveur.
En outre, nous avons configuré le domaine que nous allons utiliser pour le + serveur frontal + +. Un sous-domaine sera utilisé pour chaque client. C’est pourquoi nous avions besoin du https://www.digitalocean.com/community/tutorials/how-to-set-up-a-pagekite-front-end-server-on- a-debian-9 # prerequisites [configurations DNS dans la section des prérequis]. Nous avons également mis en place un mot de passe qui sera utilisé pour authentifier les clients. En utilisant le mot de passe réservé «++», ces configurations ont été effectuées en ajoutant la ligne `+ domain = http, https, raw: *. Pagekite.: +. Enfin, nous avons ajouté une ligne supplémentaire afin de vous connecter à l’aide de SSH (ce qui n’est pas documenté, comme indiqué à l’adresse https://stackoverflow.com/questions/25974680/setting-up-pagekite-with-my-own-frontend-toaccess -ssh [ici]): + rawports = virtual +.
Enregistrez le fichier et quittez + nano +. Redémarrez le service PageKite en lançant:
sudo systemctl restart pagekite.servicePuis activez-le pour démarrer au démarrage avec:
sudo systemctl enable pagekite.serviceMaintenant que + serveur frontal + est en cours d’exécution, testons-le en exposant un port HTTP sur + remote-host + et en le connectant à partir de + local-host +.
Étape 4 - Connexion à l’hôte derrière le NAT
Pour tester le + serveur frontal +, commençons un service HTTP sur + remote-host + et exposons-le à Internet à l’aide de PageKite, afin que nous puissions nous y connecter à partir de + local-host +. N’oubliez pas que nous devons nous connecter à + remote-host à l’aide de la console DigitalOcean, car nous avons configuré le pare-feu pour interdire les connexions SSH entrantes.
Pour démarrer un serveur HTTP à des fins de test, nous pouvons utiliser le module + http.server + de Python 3. Puisque Python est déjà installé même sur l’installation minimale de Debian et que + http.server + fait partie de la bibliothèque Python standard, pour démarrer le serveur HTTP en utilisant le port + 8000 + sur + hôte-distant +, nous allons l’exécuter:
python3 -m http.server 8000 &Comme Debian 9 utilise toujours Python 2 par défaut, il est nécessaire d’appeler Python en exécutant + python3 + pour démarrer le serveur. Le caractère de fin "+ & +" indique que la commande doit être exécutée en arrière-plan, afin que nous puissions toujours utiliser le terminal shell. La sortie indiquera que le serveur est en cours d’exécution:
Output@remote-host:~$ python3 -m http.server 8000 &
[1]
@remote-host:~$ Serving HTTP on 0.0.0.0 port 8000 ...Avec le serveur HTTP en cours d’exécution, nous pouvons établir le tunnel PageKite. Un moyen rapide de le faire consiste à utiliser le script + pagekite.py +. Nous pouvons le télécharger sur + remote-host sous:
wget https://pagekite.net/pk/pagekite.pyAprès l’avoir téléchargé, marquez-le comme exécutable en lançant:
chmod a+x pagekite.pyAvec + pagekite.py + disponible dans le répertoire en cours, nous pouvons nous connecter à + front-end server + et exposer le serveur HTTP sur le domaine + remote-host.pagekite. + En lançant ce qui suit: `et` `avec vos propres informations d’identification:
./pagekite.py --clean --frontend=pagekite.:80 --service_on=http:remote-host.pagekite.:localhost:8000:Jetons un coup d’œil aux arguments de cette commande:
-
+ - clean +est utilisé pour ignorer la configuration par défaut. -
+ - frontend = pagekite.: 80 +spécifie l’adresse de notre interface. Notez que nous utilisons le port+ 80 +, car nous avons configuré le frontal pour qu’il s’exécute sur ce port à l’étape 3. -
Dans le dernier argument,
+ - service_on = http: remote-host.pagekite.: Localhost: 8000: +, nous configurons le service que nous allons exposer (+ http +), le domaine auquel nous allons accéder. use (+ remote-host.pagekite. +), l’adresse locale et le port sur lequel le service est exécuté (+ localhost: 8000 +car nous exposons un service sur le même hôte que nous utilisons pour nous connecter à PageKite) , et le mot de passe pour se connecter au frontend (++).
Une fois cette commande exécutée, nous verrons le message + Les cerfs-volants volent et tout va bien + est affiché dans la console. Après cela, nous pouvons ouvrir une fenêtre de navigateur dans la session VNC + local-host + et l’utiliser pour accéder au serveur HTTP sur + remote-host + en accédant à l’adresse + http: //remote-host.pagekite. + `. Ceci affichera le système de fichiers pour `+ remote-host:
image: https: //assets.digitalocean.com/articles/cart-64916/local-host_accessing_remote-host_web_page.png [hôte local accédant à la page Web de l’hôte distant]
Pour arrêter la connexion de PageKite sur + remote-host +, appuyez sur + CTRL + C + dans la console + remote-host +.
Maintenant que nous avons testé + front-end-server +, configurons + remote-host + pour établir la connexion avec PageKite de manière persistante et pour démarrer au démarrage.
Étape 5 - Rendre la configuration de l’hôte persistante
La connexion entre le + hôte-distant + et le `+ serveur frontal + 'que nous avons configurés à l’étape 4 n’est pas persistante, ce qui signifie que la connexion ne sera pas rétablie lors du redémarrage du serveur. Cela posera un problème si vous souhaitez utiliser cette solution sur le long terme. Laissons donc cette configuration persistante.
Il est possible de configurer PageKit pour qu’il s’exécute en tant que service sur + remote-host, afin qu’il soit démarré au démarrage. Pour ce faire, nous pouvons utiliser les mêmes packages de distribution que nous avons utilisés pour le + serveur frontal + à l’étape 3. Dans la console + remote-host + accessible via le panneau de commande DigitalOcean, exécutez la commande suivante pour installer + dirmngr +:
sudo apt-get install dirmngrEnsuite, pour ajouter le référentiel PageKite et importer la clé GPG, exécutez:
echo deb http://pagekite.net/pk/deb/ pagekite main | sudo tee -a /etc/apt/sources.list
sudo apt-key adv --recv-keys --keyserver keys.gnupg.net AED248B1C7B2CAC3Pour mettre à jour la liste des paquets et installer PageKite, exécutez:
sudo apt-get update
sudo apt-get install pagekitePour configurer PageKite en tant que client, nous allons configurer l’adresse et le port + serveur frontal + dans le fichier + / etc / pagekite.d / 20_frontends.rc +. Nous pouvons l’éditer en utilisant + nano +:
sudo nano /etc/pagekite.d/20_frontends.rcDans ce fichier, commentez la ligne avec + default + pour éviter d’utiliser + pagekite.net + service default. De plus, configurez l’adresse et le port + serveur frontal + en utilisant le paramètre + frontend +, en ajoutant la ligne + frontend = pagekite.: 80 + à la fin du fichier. Assurez-vous de remplacer ++ par le domaine que vous utilisez.
Voici le fichier complet avec les lignes modifiées en surbrillance:
/etc/pagekite.d/20_frontends.rc
#################################[ This file is placed in the Public Domain. ]#
# Front-end selection
#
# Front-ends accept incoming requests on your behalf and forward them to
# your PageKite, which in turn forwards them to the actual server. You
# probably need at least one, the service defaults will choose one for you.
# Use the pagekite.net service defaults.
defaults
# If you want to use your own, use something like:
# or:
# frontends = COUNT:dnsname:portAprès avoir sauvegardé les modifications et quitté + nano +, poursuivez la configuration en modifiant le fichier + / etc / pagekite.d / 10_account.rc + et en définissant les informations d’identification pour la connexion à + serveur frontal +. Commencez par ouvrir le fichier en lançant:
sudo nano /etc/pagekite.d/10_account.rcPour configurer le domaine, nous allons utiliser le nom de domaine et le mot de passe pour vous connecter à notre + serveur frontal + , en modifiant les paramètres + nom de kit + et + kitesecret + `. Nous devons également commenter la dernière ligne du fichier pour activer la configuration, comme indiqué ci-après:
/etc/pagekite.d/10_account.rc
#################################[ This file is placed in the Public Domain. ]#
# Replace the following with your account details.
# Delete this line!Enregistrez et quittez l’éditeur de texte.
Nous allons maintenant configurer nos services qui seront exposés à Internet. Pour les services HTTP et SSH, PageKite inclut des exemples de fichiers de configuration avec des extensions se terminant par + .sample + dans son répertoire de configuration + / etc / pagekite.d +. Commençons par copier le fichier de configuration exemple dans un fichier valide pour HTTP:
cd /etc/pagekite.d
sudo cp 80_httpd.rc.sample 80_httpd.rcLe fichier de configuration HTTP est presque configuré. Nous n’avons qu’à ajuster le port HTTP, ce que nous pouvons faire en modifiant le fichier que nous venons de copier:
sudo nano /etc/pagekite.d/80_httpd.rcLe paramètre + service_on + définit l’adresse et le port du service que nous souhaitons exposer. Par défaut, il expose + localhost: 80 +. Comme notre serveur HTTP fonctionnera sur le port + 8000 +, il suffit de changer le numéro de port, comme indiqué ci-après:
/etc/pagekite.d/80_httpd.rc
#################################[ This file is placed in the Public Domain. ]#
# Expose the local HTTPD
service_on = http:@kitename : localhost: : @kitesecret
# If you have TLS/SSL configured locally, uncomment this to enable end-to-end
# TLS encryption instead of relying on the wild-card certificate at the relay.
#service_on = https:@kitename : localhost:443 : @kitesecret
#
# Uncomment the following to globally DISABLE the request firewall. Do this
# if you are sure you know what you are doing, for more details please see
# <http://pagekite.net/support/security/>
#
#insecure
#
# To disable the firewall for one kite at a time, use lines like this::
#
#service_cfg = KITENAME.pagekite.me/80 : insecure : TrueAprès avoir enregistré les modifications dans ce fichier de configuration, nous devons redémarrer le service pour que les modifications prennent effet:
sudo systemctl restart pagekite.servicePour démarrer le service au démarrage, activez-le avec:
sudo systemctl enable pagekite.serviceComme nous l’avons fait auparavant, utilisez le module Python + http.server + pour émuler notre serveur HTTP. Il fonctionnera déjà depuis que nous avons commencé à fonctionner en arrière-plan à l’étape 4. Cependant, si pour une raison quelconque il ne fonctionne pas, nous pouvons le redémarrer avec:
python3 -m http.server 8000 &Maintenant que le serveur HTTP et le service PageKite sont en cours d’exécution, ouvrez une fenêtre de navigateur dans la session VNC + local-host + et utilisez-la pour accéder à + remote-host + en utilisant l’adresse + http: // remote- host.pagekite. + `. Ceci affichera le système de fichiers `+ remote-host + dans le navigateur.
Nous avons vu comment configurer un serveur frontal PageKite et un client pour exposer un serveur HTTP local. Ensuite, nous allons configurer + remote-host + pour exposer SSH et autoriser les connexions distantes.
Étape 6 - Exposer SSH avec PageKite
Outre HTTP, PageKite peut être utilisé pour proxy d’autres services, tels que SSH, ce qui est utile pour accéder à des hôtes à distance derrière NAT dans des environnements où il n’est pas possible de modifier la mise en réseau ni les configurations d’un routeur.
Dans cette section, nous allons configurer + remote-host + pour exposer son service SSH à l’aide de PageKite, puis ouvrir une session SSH à partir de + local-host +.
Comme nous l’avons fait pour configurer HTTP avec PageKite, pour SSH, nous allons copier le fichier de configuration exemple dans un fichier valide afin d’exposer le service SSH sur + remote-host +:
cd /etc/pagekite.d
sudo cp 80_sshd.rc.sample 80_sshd.rcCe fichier est préconfiguré pour exposer le service SSH exécuté sur le port + 22 +, qui correspond à la configuration par défaut. Voyons son contenu:
nano 80_sshd.rcCela vous montrera le fichier:
/etc/pagekite.d/80_sshd.rc
#################################[ This file is placed in the Public Domain. ]#
# Expose the local SSH daemon
service_on = raw/22:@kitename : localhost:22 : @kitesecretCe fichier est très similaire à celui utilisé pour exposer HTTP. Les seules différences sont le numéro de port, qui correspond à «+ 22 » pour SSH, et le protocole, qui doit être défini sur « raw +» lors de l’exposition de SSH.
Puisque nous n’avons pas besoin d’apporter de modifications ici, quittez le fichier.
Redémarrez le service PageKite:
sudo systemctl restart pagekite.serviceSur + localhost, nous utiliserons le client SSH pour nous connecter à` + remote-host`. PageKite tunnelise les connexions via HTTP. Ainsi, pour utiliser SSH sur PageKite, nous aurons besoin d’un proxy HTTP. Vous pouvez utiliser plusieurs options de proxies HTTP à partir des référentiels Debian, telles que http://nc110.sourceforge.net/ [Netcat] (+ nc +) et https://github.com/bryanpkc/corkscrew [` + tire-bouchon + ]. Pour ce tutoriel, nous allons utiliser `+ corkscrew +, car il nécessite moins d’arguments que + nc +.
Pour installer + corkscrew sur` + local-host to`, utilisez + apt-get install avec le paquetage du même nom:
sudo apt-get install corkscrewEnsuite, générez une clé SSH sur + local-host et ajoutez la clé publique au fichier` + .ssh / registered_keys` de + remote-host +. Pour ce faire, suivez le guide https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-debian-9[Comment configurer les clés SSH sous Debian 9, y compris la section * Copier la clé publique manuellement * à l’étape 2.
Pour vous connecter à un serveur SSH à l’aide d’un proxy, nous allons utiliser + ssh + avec l’argument + -o + pour transmettre + ProxyCommand + et spécifier + corkscrew + en tant que proxy HTTP. De cette façon, sur + local-host +, nous exécuterons la commande suivante pour vous connecter à + remote-host + via le tunnel de PageKite:
ssh @remote-host.pagekite. -i ~/id_rsa -o "ProxyCommand corkscrew %h 80 %h %p"Remarquez que nous avons fourni des arguments à + tire-bouchon +. Les +% h + et +% p + sont des jetons que le client SSH remplace par le nom de l’hôte distant (+ remote-host.pagekite. +) Et le port distant (+ 22 +, utilisé implicitement par ` + ssh + ) quand il lance + tire-bouchon + . Le `+ 80 + fait référence au port sur lequel tourne PageKite. Ce port fait référence à la communication entre le client PageKite et le serveur frontal.
Une fois que vous avez exécuté cette commande sur + local-host +, l’invite de ligne de commande pour + remote-host + apparaîtra.
Maintenant que notre connexion SSH fonctionne via PageKite, définissons ensuite une session VNC sur + serveur_distant + et accédons à partir de + local-host + en utilisant VNC sur SSH.
Étape 7 - Utilisation de VNC sur SSH
Nous pouvons maintenant accéder à un hôte distant à l’aide d’un shell, ce qui résout bon nombre des problèmes liés aux serveurs cachés derrière NAT. Cependant, dans certaines situations, nous avons besoin d’accéder à l’interface utilisateur graphique. SSH offre un moyen de tunnelliser n’importe quel service dans sa connexion, tel que VNC, qui peut être utilisé pour un accès à distance graphique.
Avec + remote-host + configuré pour exposer SSH à l’aide de notre serveur frontal, utilisons une connexion SSH pour tunnel VNC et accédez à l’interface graphique + remote-host +.
Comme nous avons déjà configuré une session VNC pour qu’elle démarre automatiquement sur + remote-host +, nous utiliserons + + local-host + pour vous connecter à + remote-host + en utilisant + ssh + avec l’argument + -L + :
ssh @remote-host.pagekite. -i ~/id_rsa -o "ProxyCommand corkscrew %h 80 %h %p" -L5902:localhost:5901L’argument + -L + spécifie que les connexions à un port local donné doivent être transférées à un hôte et à un port distants. Avec cet argument, nous avons fourni un numéro de port suivi de deux points, puis une adresse IP, un domaine ou un nom d’hôte, suivi d’un autre point et d’un numéro de port. Voyons ces informations en détail:
-
Le premier numéro de port fait référence à celui que nous allons utiliser sur l’hôte qui démarre la connexion SSH (dans ce cas,
+ local-host +), pour recevoir la connexion en tunnel de l’hôte distant. Dans ce cas, du point de vue de+ local-host +, la session VNC de+ remote-host +sera disponible localement, sur le port+ 5902 +. Nous ne pouvions pas utiliser le port+ 5901 +car il est déjà utilisé sur+ local-host +pour sa propre session VNC. -
Après les deux premiers points, nous fournissons le nom d’hôte (ou l’adresse IP) du périphérique qui dessert la session VNC que nous souhaitons utiliser comme tunnel. Si nous fournissons un nom d’hôte, il sera résolu en une adresse IP par l’hôte qui sert SSH. Dans ce cas, étant donné que
+ remote-hostsert la connexion SSH et que la session VNC est également desservie par ce même hôte, nous pouvons utiliser` + localhost`. -
Après le deuxième point, nous fournissons le port dans lequel le service à tunneler est servi. Nous utilisons le port
+ 5901 +, car VNC s’exécute sur ce port sur le+ remote-host.
Une fois la connexion établie, un shell distant nous sera présenté sur + remote-host +.
Nous pouvons maintenant atteindre la session + hôte distant + VNC à partir de + hôte local + en nous connectant au port + 5902 + lui-même. Pour ce faire, ouvrez un shell à partir de l’interface graphique + local-host + de votre client VNC, puis exécutez:
vncviewer localhost:5902En fournissant le mot de passe VNC + remote-host +, nous pourrons accéder à son environnement graphique.
Cette configuration peut être utile pour les équipes de support utilisant un accès à distance. Il est possible d’utiliser SSH pour tunneler n’importe quel service accessible par + remote-host +. De cette façon, nous pourrions configurer + remote-host + comme passerelle vers un réseau local connecté avec de nombreux hôtes, y compris certains exécutant Windows ou un autre système d’exploitation. Tant que les hôtes ont un serveur VNC avec une session VNC configurée, il serait possible d’y accéder avec une interface utilisateur graphique via SSH tunnelé par notre PageKite + serveur frontal +.
Dans la dernière étape, nous allons configurer l’interface de PageKite pour prendre en charge davantage de clients avec des mots de passe différents.
Étape 8 - Configuration du serveur frontal pour plusieurs clients (facultatif)
Supposons que nous utilisions notre + serveur frontal + pour offrir un accès à distance à de nombreux clients. Dans cette configuration multi-utilisateurs, il serait préférable de les isoler, en utilisant un nom de domaine et un mot de passe différents pour que chacun puisse se connecter à notre serveur. Pour ce faire, vous pouvez notamment exécuter plusieurs services PageKite sur notre serveur sur différents ports, chacun configuré avec son propre sous-domaine et son propre mot de passe, mais cela peut être difficile à organiser.
Heureusement, l’interface de PageKite prend en charge la configuration de plusieurs clients, de sorte que nous puissions utiliser le même service sur un seul port. Pour ce faire, nous configurerions le serveur avec les noms de domaine et les mots de passe.
Comme nous avons configuré l’entrée DNS générique + *. Pagekite. + Indiquant notre serveur frontal + + , les entrées DNS des sous-domaines tels que ` remote-host.client-1.pagekite. ` Peuvent également pointez sur notre serveur, afin que nous puissions utiliser des domaines se terminant par ` client1.pagekite. ` et ` client2.pagekite. +` pour identifier les hôtes de différents clients avec des mots de passe différents.
Pour cela, ouvrez le fichier + / etc / pagekite.d / 20_frontends.rc +:
sudo nano /etc/pagekite.d/20_frontends.rcAjoutez les domaines en utilisant le mot-clé + domain + et définissez des mots de passe différents pour chacun. Pour configurer les domaines que nous avons mentionnés, ajoutez:
/etc/pagekite.d/20_frontends.rc
#################################[ This file is placed in the Public Domain. ]#
# Front-end selection
#
# Front-ends accept incoming requests on your behalf and forward them to
# your PageKite, which in turn forwards them to the actual server. You
# probably need at least one, the service defaults will choose one for you.
# Use the pagekite.net service defaults.
# defaults
# If you want to use your own, use something like:
# frontend = hostname:port
# or:
# frontends = COUNT:dnsname:port
isfrontend
ports=80,443
protos=http,https,raw
domain=http,https,raw:*.pagekite.:
rawports=virtualEnregistrez et quittez le fichier.
Après avoir modifié les fichiers de configuration, redémarrez PageKite:
sudo systemctl restart pagekite.serviceSur les hôtes distants, configurons le client PageKite pour qu’il se connecte en fonction des nouveaux domaines et mots de passe. Par exemple, dans + remote-host +, pour vous connecter à l’aide de + client-1.pagekite. +, Modifiez le fichier + / etc / pagekite.d / 10_account.rc +, où les informations d’identification à connecter à `+ serveur frontal + `sont stockés:
sudo nano /etc/pagekite.d/10_account.rcRemplacez + nom de kit + et + + kitesecret + par les informations d’identification appropriées. Pour le domaine + remote-host.client-1.pagekite. +, La configuration serait la suivante:
/etc/pagekite.d/10_account.rc
#################################[ This file is placed in the Public Domain. ]#
# Replace the following with your account details.
# Delete this line!Enregistrez et quittez le fichier.
Après avoir modifié le fichier, redémarrez le service PageKite:
sudo systemctl restart pagekite.serviceMaintenant, sur + localhost, nous pouvons nous connecter à` + remote-host` via SSH avec:
ssh @remote-host.client-1.pagekite. -i ~/id_rsa -o "ProxyCommand corkscrew %h 80 %h %p"Nous pourrions utiliser le domaine + client-2.pagekite. + Pour un autre client. De cette façon, nous pourrions administrer les services de manière isolée, avec la possibilité de changer le mot de passe d’un client ou même de désactiver l’un d’entre eux sans affecter l’autre.
Conclusion
Dans cet article, nous avons configuré un serveur frontal PageKite privé sur un droplet Debian 9 et l’avons utilisé pour exposer les services HTTP et SSH sur un hôte distant derrière NAT. Nous nous sommes ensuite connectés à ces services à partir d’un serveur + local-host + et avons vérifié la fonctionnalité PageKite. Comme nous l’avons mentionné, cela pourrait être une configuration efficace pour les applications d’accès distant, car nous pouvons canaliser d’autres services dans la connexion SSH, tels que VNC.
Si vous souhaitez en savoir plus sur PageKite, consultez les informations de support PageKite. Si vous souhaitez approfondir la mise en réseau avec Droplets, consultez la page DigitalOcean Networking Documentation.