Exigences réseau

Utilisez cette page comme demande de changement pour votre équipe réseau. Le client a besoin d’une seule destination sortante, atteinte à travers votre proxy, et n’ouvre rien en entrée.

Une seule dépendance sortante

Le client tourne sur la machine qui exécute l’agent, dans le cycle de vie de l’agent lui-même. Il contacte OpenLatch pour trois choses : récupérer les politiques avec lesquelles il décide, transmettre l’enregistrement de ce qu’il a décidé, et s’authentifier. Les trois vont vers une seule destination sur un seul port. La télémétrie produit et les rapports de plantage, facultatifs, vont vers cette même destination : OpenLatch n’ajoute aucune autre destination, que vous les laissiez actifs ou que vous les coupiez.

Propriété	Valeur
Sens	Sortant uniquement. Le client n’ouvre aucun port d’écoute sur une interface réseau, et rien sur la machine ne devient joignable depuis le réseau
Destination	`app.openlatch.ai`, sur TCP 443
Transport	HTTPS. TLS est vérifié avec le magasin de confiance du système d’exploitation, plus un paquet de certificats facultatif fusionné par-dessus. La vérification ne peut pas être désactivée
À travers votre proxy	Oui : HTTP et HTTPS CONNECT, SOCKS5, et configuration automatique de proxy là où le système d’exploitation la prend en charge, avec authentification Basic et Kerberos (Negotiate)
Liste d’adresses IP autorisées	Non prise en charge. Il n’existe aucune plage d’adresses statique : autorisez par nom de domaine complet et par SNI
Certificats	Aucun émis par OpenLatch, et aucun exigé de votre part

Figure 1. Un parc de machines derrière un proxy d’entreprise : une seule destination sortante, rien en entrée.

Flux sortants requis

C’est le tableau à coller dans une demande de changement. La première ligne est ce dont OpenLatch a besoin pour fonctionner, et c’est la seule destination qu’une machine qui exécute le client demande à OpenLatch. La deuxième n’est nécessaire que pendant l’installation ou la mise à jour du client ; un parc qui dispose d’un miroir interne de paquets la pointe sur ce miroir. La troisième n’est nécessaire que pour installer avec l’un des deux scripts. La quatrième ne concerne que les navigateurs.

Destination	Port	Sens	Protocole	Usage	Autorisation
`app.openlatch.ai`	TCP 443	Sortant	HTTPS	Politiques, enregistrements de décisions, authentification, et la télémétrie produit et les rapports de plantage facultatifs	Par nom et SNI. Il n’existe aucune plage d’adresses statique
Votre registre de paquets : `registry.npmjs.org`, sauf si vous pointez le client sur un miroir	TCP 443	Sortant	HTTPS	Installer le client, et télécharger une mise à jour quand vous l’autorisez	Par nom, ou par le nom de votre miroir interne. Nécessaire uniquement pendant une installation ou une mise à jour
`openlatch.ai`	TCP 443	Sortant	HTTPS	Télécharger le script d’installation, `install.sh` ou `install.ps1`, et le rapport d’installation qu’il envoie	Par nom. Nécessaire uniquement pour une installation par script
`challenges.cloudflare.com`, depuis le navigateur de toute personne qui se connecte à la console	TCP 443	Sortant	HTTPS	La vérification que l’étape e-mail effectue à la connexion	Par nom, pour les navigateurs uniquement. Aucune machine qui exécute le client ne le contacte

Le navigateur de l’administrateur

La connexion à la console commence par une étape e-mail, et cette étape effectue dans le navigateur une courte vérification que le visiteur est une personne. La vérification est servie depuis challenges.cloudflare.com : les navigateurs avec lesquels vos administrateurs se connectent doivent atteindre ce nom sur TCP 443. Un navigateur qui ne peut pas l’atteindre échoue à chaque fois. Cette exigence ne concerne que les navigateurs : app.openlatch.ai reste la seule destination dont une machine qui exécute le client a besoin.

Le trafic propre de vos agents

Vos agents atteignent leurs points d’accès de modèles exactement comme avant l’installation d’OpenLatch. OpenLatch ne termine ni ne re-signe ce trafic, et n’y ajoute aucune destination. Ces points d’accès doivent rester joignables et être exemptés de la mise en tampon des réponses et de l’inspection des flux, pour qu’une réponse en flux ne soit pas retenue en chemin vers la personne qui l’attend.

Un équipement qui met la réponse en tampon, ou l’analyse comme un corps entier, retient le flux jusqu’à la fin puis le libère d’un bloc. La requête aboutit quand même ; le développeur voit un agent qui semble se figer puis affiche tout d’un coup.

Pour les produits de proxy qui orientent le trafic par application plutôt que par destination, le nom du processus est openlatch sur macOS et Linux et openlatch.exe sur Windows. Utilisez ce nom dans une définition d’application personnalisée.

Matrice de prise en charge des proxys

Répondez contrôle par contrôle. Une ligne « Non » est un choix de conception plutôt qu’un manque, et chacune indique la voie à suivre à la place.

Contrôle réseau	Pris en charge	Traitement	Remarques
Proxy HTTP ou HTTPS CONNECT non authentifié	Oui	Découvert à l’installation, ou fourni à l’installation	La forme courante en entreprise. La route qui fonctionne est enregistrée sur la machine
Authentification Basic	Oui	L’identifiant est demandé lors d’un défi et conservé dans le magasin d’identifiants du système d’exploitation	Jamais écrit en clair dans un fichier
Kerberos (Negotiate)	Oui	Utilise l’identité de la session ouverte, par le mécanisme du système d’exploitation	Le principal de service vaut par défaut le service HTTP de l’hôte du proxy et peut être remplacé à l’installation. Un ticket manquant ou expiré est signalé avec son remède
NTLM	Non	Non pris en charge, par choix de conception	Microsoft a déprécié NTLM, et un client qui y redescend discrètement va à l’encontre de ce pour quoi il a été déployé. Utilisez Negotiate, ou un chemin non authentifié pour le client
Configuration automatique de proxy (PAC ou WPAD)	Oui, sur Windows et macOS	L’URL est confiée au résolveur du système d’exploitation	Refusée sur Linux, où aucun résolveur de configuration automatique n’est disponible pour le client. Définissez-y la route explicitement
SOCKS5	Oui	Une route `socks5://` ou `socks5h://`	La résolution de noms reste locale avec `socks5` et passe au proxy avec `socks5h`
Proxy transparent	Oui	Aucune configuration sur la machine ; le trafic est intercepté sur le chemin	Combinez-le avec la ligne d’inspection TLS si l’équipement re-signe la connexion
Inspection TLS avec une autorité de certification d’entreprise	Oui	La racine d’interception va dans le magasin de confiance du système d’exploitation, ou est fournie en paquet PEM à l’installation	Le paquet est fusionné par-dessus les racines du système, jamais en remplacement, et la vérification n’est jamais désactivée
Certificats clients mTLS vers le proxy	Non	—	Le client ne présente aucun certificat client. Utilisez l’un des modes d’authentification pris en charge
Liste d’adresses IP autorisées pour les flux sortants d’OpenLatch	Non	—	Il n’existe aucune plage d’adresses statique. Autorisez `app.openlatch.ai` par nom et SNI

Configurer la route

Comment la route est trouvée

Sur la plupart des machines d’entreprise, l’installation trouve la route sans qu’on la lui indique. Elle sonde ce qui est déjà configuré, puis parcourt les réglages du système d’exploitation, y compris la configuration automatique de proxy sur Windows et macOS. Elle ne pose une question que si rien de cela n’atteint la console, une fois, dans un terminal. Une installation sans surveillance qui ne trouve pas de route s’arrête avec un rapport qui nomme chaque candidat essayé, plutôt que de passer en direct sans le dire.

La route qui a permis l’installation est enregistrée sur la machine. C’est important : le client démarre avec la session de l’utilisateur et n’hérite pas des variables du shell d’installation, si bien qu’une route qui n’existait que dans une variable d’environnement serait perdue au redémarrage suivant.

Fournir la route à l’installation

Quand la découverte ne peut pas fonctionner, ou qu’une installation gérée tourne sans terminal pour poser la question, fournissez la route directement à l’installation. Fournissez en même temps le paquet de certificats si le système d’exploitation n’approuve pas déjà la racine d’interception.

Retenez l’inscription avec OPENLATCH_NO_INIT et lancez-la dans une seconde étape, pour que les options atteignent la commande qui l’effectue. Exportez la variable avant le lancement du script, pour que le shell qui lit le script la porte aussi.

Sur macOS et Linux :

export OPENLATCH_NO_INIT=1
curl -LsSf https://openlatch.ai/install.sh | sh
~/.local/bin/openlatch init --proxy http://proxy.corp:8080 --ca-bundle /etc/ssl/corp-root.pem

Sur Windows :

$env:OPENLATCH_NO_INIT = "1"
powershell -ExecutionPolicy Bypass -c "irm https://openlatch.ai/install.ps1 | iex"
& "$env:LOCALAPPDATA\openlatch\bin\openlatch.exe" init --proxy http://proxy.corp:8080 --ca-bundle C:\corp\corp-root.pem

Sur une machine qui dispose déjà de Node.js, npx @openlatch/client init accepte les mêmes options en une seule étape :

npx @openlatch/client init --proxy http://proxy.corp:8080 --ca-bundle /etc/ssl/corp-root.pem

Une liste d’exceptions peut être fournie avec la route, dans la syntaxe habituelle. Le trafic qui ne quitte pas la machine ne passe pas par le proxy et ne demande aucune exception.

Quand la politique interdit à une machine de sortir sans le proxy, le client peut être configuré pour refuser une connexion directe si aucune route n’est résolue. Il signale alors un échec de route au lieu de contourner discrètement vos contrôles. Configuration du client liste les réglages.

Gestion des identifiants

Un identifiant de proxy est conservé dans le magasin d’identifiants du système d’exploitation : le Gestionnaire d’identifiants sur Windows, le Trousseau sur macOS, Secret Service sur Linux, et un fichier chiffré sur un hôte sans interface qui n’en dispose pas. Il n’est jamais écrit en clair dans un fichier de configuration. Partout où une URL de proxy est affichée ou journalisée, elle apparaît sous la forme user:*****@host. Une URL de proxy qui porte un mot de passe en ligne de commande est refusée, car une ligne de commande est lisible par n’importe quel processus de la machine.

Inspection TLS

La connexion à la console fonctionne sous inspection et ne demande aucune exception. Le client fait des appels HTTPS ordinaires de type requête-réponse, vérifie avec le magasin de confiance du système d’exploitation, et n’épingle aucun certificat. Placez la racine d’interception dans le magasin de confiance là où votre parc le fait déjà, ou fournissez-en une copie PEM à l’installation. Le paquet est fusionné par-dessus les racines du système : une machine continue de faire confiance à tout ce qu’elle approuvait déjà.

Les points d’accès de modèles de vos agents font exception, et la demande y est étroite : exemptez-les de la mise en tampon des réponses et de l’inspection des flux, et laissez le reste de votre politique d’inspection intact.

Comportement hors ligne et dégradé

Le client actualise ses politiques depuis la console en arrière-plan. Chaque décision est prise sur la machine, avec les politiques déjà présentes : aucun appel réseau n’est sur le chemin de décision. C’est ce qui permet à un verdict de survivre à une route coupée.

Là où la machine détient des politiques, elle continue de les appliquer quoi que fasse le réseau. Là où elle n’en détient aucune, elle autorise l’action et marque l’enregistrement pour indiquer que la décision a été prise sans politique. Rien n’échoue en silence.

Situation	Ce que fait la machine	Ce que vous voyez
La console est injoignable	Continue d’appliquer les politiques qu’elle détient et réessaie en arrière-plan. Les enregistrements sont conservés sur la machine	La machine cesse de se signaler. `openlatch status` la montre déconnectée, avec des politiques présentes
Les politiques de la machine n’ont pas été actualisées depuis un moment	Continue de les appliquer. Les politiques n’expirent pas	Un avertissement de péremption. La péremption est signalée, jamais suivie d’effet
L’identifiant de la vague est révoqué ou renouvelé, et la console le refuse	Cesse de récupérer les mises à jour, continue d’appliquer ce qu’elle détient, et reprend seule dès qu’un identifiant valide est en place	Un avertissement d’authentification sur la machine, et plus aucun signalement dans la console
Votre organisation n’a encore publié aucune politique	Maintient en vigueur ce qu’elle détient déjà	La machine se signale comme connectée, sans rien à récupérer
Une mise à jour arrive endommagée ou sous une forme que la machine ne reconnaît pas	La rejette et garde les politiques précédentes. Une mise à jour endommagée ne prend jamais effet	Un avertissement d’intégrité sur la machine, avec les politiques précédentes toujours en vigueur
La copie locale des politiques est modifiée sur la machine	La supprime. La machine fonctionne sans politique jusqu’à la prochaine actualisation réussie	Chaque verdict est marqué comme décidé sans politique, et la machine signale la perte
Aucune politique n’a jamais atteint la machine	Rend Allow : une machine ne bloque jamais sans politique	Chaque verdict est marqué comme décidé sans politique
Le client ne tourne pas	L’action se poursuit et n’est pas retenue	`openlatch status` signale que le client ne tourne pas, et la console ne montre aucune activité récente pour la machine
Les enregistrements ne peuvent pas être transmis	Réessaie, puis les conserve sur la machine et les envoie quand la console redevient joignable	Un trou dans la console qui se referme quand la machine se reconnecte. La réserve est bornée : au-delà de sa limite de taille, les enregistrements non envoyés les plus anciens sont abandonnés, et le journal du daemon consigne un avertissement `OL-1204`
Vous passez toutes les politiques en Monitor depuis la console	Chaque machine applique le changement à sa prochaine actualisation, et consigne ce qu’elle aurait fait	Le changement, dans la console, sans accès nécessaire à une machine. Les décisions continuent d’être enregistrées

Vérifier la route

Lancez ces commandes sur la première machine avant la vague, puis sur toute machine qui signale un problème de connexion.

openlatch status
openlatch doctor
openlatch system proxy test

Commande	Ce qu’elle prouve
`openlatch status`	Si la machine est connectée à la console, si des politiques sont présentes, et quels agents sont raccordés. Elle répond même quand la route est coupée, c’est-à-dire exactement quand vous en avez besoin
`openlatch doctor`	La machine entière, avec une cause et un remède pour chaque point relevé. Elle signale le saut par votre proxy séparément de la connexion à la console : un proxy hors service et une console injoignable ne ressemblent jamais à la même panne
`openlatch system proxy test`	La route elle-même, sondée saut par saut. Elle s’arrête au saut qui échoue et le nomme

Déployer le client couvre son installation, et Vérifier et déployer la vérification complète d’une machine.

En bref

Approuvez une seule entrée pour les machines : app.openlatch.ai sur TCP 443, en sortie. Aucun port entrant.
Les navigateurs qui se connectent à la console ont aussi besoin de challenges.cloudflare.com sur TCP 443. Aucune machine qui exécute le client ne le contacte.
Autorisez par nom et SNI, pas par adresse. Il n’existe aucune plage d’adresses statique.
Vos agents atteignent leurs points d’accès de modèles comme avant. Gardez ces points d’accès joignables et exemptés de la mise en tampon des réponses et de l’inspection des flux.
L’inspection TLS ne demande aucune exception pour la connexion à la console. Les proxys Basic, Kerberos, SOCKS5, transparents et à configuration automatique sont pris en charge. NTLM ne l’est pas : prévoyez un chemin Negotiate ou non authentifié.
Une route coupée dégrade l’acheminement, pas l’application. La machine continue de décider avec les politiques qu’elle détient, les enregistrements attendent que la console soit joignable, et les deux états apparaissent dans openlatch status.