Activer ou désactiver l’accès à Internet
Lors de la création d’une sandbox, vous pouvez utiliser le paramètreallowInternetAccess / allow_internet_access pour configurer la connectivité Internet. L’accès à Internet est activé par défaut, mais il peut être désactivé pour les charges de travail ayant des exigences de sécurité plus strictes.
Transmettre une valeur falsy à
allowInternetAccess / allow_internet_access a le même effet que l’ajout de ['0.0.0.0/0'] à network.denyOut / network.deny_out, ce qui bloque toutes les destinations.Contrôle réseau granulaire
La configuration réseau offre un contrôle plus granulaire du trafic sortant en vous permettant de définir des listes d’autorisation et de refus.Listes d’autorisation et de refus
Les adresses IP, les blocs CIDR ou les noms de domaine auxquels la sandbox est autorisée à accéder peuvent être spécifiés.Le CIDR
'0.0.0.0/0' / "0.0.0.0/0" est un raccourci pour « toutes les destinations ». Une constante ALL_TRAFFIC exportée se résout à la même valeur 0.0.0.0/0 si vous préférez une alternative nommée au littéral.Filtrage basé sur le domaine
Vous pouvez spécifier des noms d’hôte dansallowOut / allow_out afin d’autoriser le trafic sortant vers des domaines sélectionnés. Lorsque le filtrage basé sur le domaine est activé, tout le trafic restant doit être bloqué via denyOut / deny_out. Les entrées de domaine sont uniquement prises en charge dans les listes d’autorisation et ne peuvent pas être utilisées dans les listes de refus.
Chaque fois qu’un domaine apparaît dans la configuration, le serveur de noms par défaut
8.8.8.8 est autorisé automatiquement afin que la résolution DNS continue de fonctionner.Le filtrage par domaine s’applique uniquement à HTTP sur le port 80 (inspecté via l’en-tête Host) et à TLS sur le port 443 (inspecté via SNI). Tout autre port revient à une correspondance basée sur CIDR, et les protocoles UDP tels que QUIC/HTTP3 ne peuvent pas être filtrés par domaine.
Comportement des connexions TCP bloquées
En raison de l’architecture du pare-feu, une connexion sortante bloquée peut tout de même sembler réussir depuis l’intérieur de la sandbox. Le pare-feu doit d’abord accepter la connexion TCP avant de pouvoir évaluer si la destination cible est autorisée. Par conséquent, le code exécuté dans la sandbox peut voir la connexion réussir et le socket s’ouvrir, même si la destination est bloquée. Dans ce cas, aucun trafic n’est réellement transmis au point de terminaison distant. Pour confirmer que la destination est accessible, validez une réponse au niveau applicatif au lieu de vous fier uniquement à la réussite de la connexion TCP. Par exemple, vérifiez un code d’état HTTP, une négociation TLS terminée ou les octets de réponse attendus du protocole. Ce comportement est une limitation actuelle de la manière dont le trafic sortant de la sandbox est routé via notre pare-feu et pourra être mis à jour à l’avenir.Règles de priorité
Si des règles d’autorisation et de refus sont toutes deux configurées, les règles d’autorisation sont prioritaires. Par conséquent, toute adresse IP qui apparaît dans les deux listes sera tout de même autorisée.network ne prennent effet que lorsque la sandbox est créée — fournissez-les à Sandbox.create. Une fois que la sandbox existe, ils sont fixes et ne peuvent pas être modifiés.
URL publique de la sandbox
Les services dans une sandbox sont accessibles en utilisant l’URL publique de la sandbox.Connexion à un serveur exécuté dans la sandbox
Vous pouvez vous connecter à un serveur exécuté dans la sandbox à l’aide de la méthode décrite précédemment ; par exemple, démarrez un serveur HTTP léger sur le port 3000 pour servir des fichiers depuis son répertoire de lancement.Masquage des en-têtes Host des requêtes
Vous pouvez utiliser l’optionmaskRequestHost / mask_request_host pour personnaliser l’en-tête Host envoyé aux services exécutés dans la sandbox. C’est utile lorsque votre application s’attend à ce que les requêtes suivent un format d’hôte spécifique.
${PORT} dans le masque est remplacé par le numéro de port réel du service adressé.