tlstunnel
1.0.0
Il s'agit d'une MirageOS Unikernel acceptant les connexions TLS via l'interface réseau publique (service) sur Frontend-Port, et les proxyant à l'aide de TCP via l'interface de réseau privé au backend-ip et au porte-backend. Un client se connectant à TlStunnel doit établir une connexion TLS, dont la charge utile est transmise au service backend via TCP.
TlStunnel peut être utilisé pour l'équilibrage de charge - en utilisant plusieurs tlstunnel sur le frontend faisant des opérations de crypto coûteuses (asymétriques TLS poignées de main et cryptographie symétrique) avec un seul (ou plusieurs) services backend qui communiquent via un TCP ordinaire.
En ce qui concerne la sécurité, seul le tlStunnel a besoin d'accès à la clé privée du ou des certificats X.509. Lorsque TlStunnel est configuré pour effectuer l'authentification des clients, seuls les clients valides peuvent accéder au service backend, limitant radicalement la surface d'attaque.
L'exécution de TlStunnel nécessite deux adresses IP: l'une est confrontée à l'une, l'autre est sur le réseau privé (où les connexions TCP sont transmises). La configuration peut être effectuée via un utilitaire de ligne de commande sur le réseau privé. Le certificat X.509 doit être disponible via DNS (voir DNS-Primaire-Git et DNS-Lesencrypt-Secondary).
Considérons que votre adresse IP publique est 1.2.3.4/24 (avec la passerelle par défaut 1.2.3.1). Vous utilisez 192.168.0.4/24 comme réseau privé. Votre serveur DNS est 1.2.3.5 avec la clé tlstunnel._update.example.org.
Démarrage de tlstunnel:
$ truncate -s 1m /var/db/tlstunnel
$ solo5-hvt --net:service=tap0 --net:private=tap10 --block:storage=/var/db/tlstunnel --
tlstunnel/unikernel/dist/tlstunnel.hvt --ipv4=1.2.3.4/24 --ipv4-gateway=1.2.3.1
--private-ipv4=192.168.0.4/24 --domains=example.org
--dns-server=1.2.3.5 --dns-key=tlstunnel._update.example.org:SHA256:m2gls0y3ZMN4DVKx37x/VoKEdll4J2A9qNIl6JIz2z4=
--key-seed=ROkD8o/Xrc4ScDdxM8cV1+4eQiWUEul+3I1twW+I15E=
--key=9Fe92fogykIAPBJZU4FUsmpRsAy6YDajIkdSRs650zM=Maintenant, une fois que TlStunnel a réussi à obtenir un certificat via DNS, vous pouvez déjà vous connecter à https://1.2.3.4 et devrait voir le certificat:
$ openssl s_client -connect 1.2.3.4:443
$ curl https://1.2.3.4 Pour configurer le transfert de TlStunnel, où un nom d'hôte spécifié sera transmis à une adresse IP et à une paire de ports, vous devez utiliser le tlstunnel-client binaire à partir du sous-dossier client . La communication est authentifiée en utilisant le secret partagé passé à TlStunnel ( --key=secret ).
La configuration est conservée dans le périphérique de bloc (de manière robuste, c'est-à-dire sur le changement d'abord, les nouvelles données sont écrites et ensuite le superblock est des mises à jour).
$ cd tlstunnel/client
$ dune build
# Listing all configured hostnames:
$ _build/install/default/bin/tlstunnel-client list --key=9Fe92fogykIAPBJZU4FUsmpRsAy6YDajIkdSRs650zM= -r 192.168.0.4:1234
# Adding a new forward:
$ _build/install/default/bin/tlstunnel-client add --key=9Fe92fogykIAPBJZU4FUsmpRsAy6YDajIkdSRs650zM= -r 192.168.0.4:1234 test.example.org 192.168.0.42 80
# Removing a foward:
$ _build/install/default/bin/tlstunnel-client remove --key=9Fe92fogykIAPBJZU4FUsmpRsAy6YDajIkdSRs650zM= -r 192.168.0.4:1234 test.example.orgPour installer ce Unikernel à partir de la source, vous devez faire installer OPAM (> = 2.0.0) et OCAML (> = 4.08.0). De plus, le mirage est requis (> = 4.5.0). Veuillez suivre les instructions d'installation.
Les étapes suivantes cloneront ce référentiel GIT et compileront l'unikernel:
$ git clone https://github.com/robur-coop/tlstunnel.git
$ cd tlstunnel/unikernel && mirage configure -t < your-favourite-target >
$ make depend
$ make buildLes binaires sont disponibles dans les builds OPAM reproductibles, voir le déploiement de MirageOS Binaryos et des constructions MirageOS Unikernel reproductibles pour plus de détails.
Veuillez ouvrir un problème si vous avez des questions, des demandes de fonctionnalités ou des commentaires.
