Compatibilidad de NO_PROXY entre curl, .NET y contenedores
Convierta una política compartida de enrutamiento directo en configuración específica del cliente usando un pequeño conjunto de destinos representativos.
Un equipo coloca una cadena de omisión en un archivo de entorno compartido. curl va directo, otra aplicación usa el proxy y un contenedor se comporta de forma distinta otra vez. El archivo compartido distribuía los mismos caracteres. Pero no distribuía un analizador compartido.
El objeto duradero es la política: qué destinos deben ser directos y en qué condiciones. Manténgala separada de la cadena que necesita cada programa.
Escriba primero las rutas esperadas
Use direcciones representativas, incluidos los límites y no solo los éxitos fáciles:
| Forma del destino | Pregunta para el responsable de la política |
|---|---|
| Dominio padre | ¿Debe omitirse, o solo sus hijos? |
| Un subdominio | ¿Hereda la misma ruta? |
| Una IP privada literal | ¿Es esa dirección accesible directamente desde este cliente? |
| El mismo servicio bajo un nombre de host | ¿Deben coincidir las solicitudes basadas en nombre y en dirección? |
| Otro puerto de servicio | ¿La excepción cubre el host o un solo receptor? |
Después identifique a los consumidores: el demonio que descarga una imagen, el programa dentro del contenedor, una biblioteca HTTP de un lenguaje y un navegador interactivo pueden ser entradas separadas. Una configuración de proxy del cliente Docker puede rellenar valores de entorno del contenedor sin que cada cliente interno tenga que implementar las mismas reglas de coincidencia.
Traduzca en lugar de copiar a ciegas
Un ejemplo documentado de una diferencia real es el límite del dominio padre. La exclusión de dominio de curl cubre el dominio nombrado y sus hijos coincidentes. La política de entorno de .NET distingue el nombre desnudo de la forma de subdominio con punto inicial. Una regla universal de añadir siempre un punto inicial no puede expresar ambas políticas de forma fiable.
La compatibilidad con rangos IP también depende del consumidor y de su versión. Una máquina con un curl autónomo nuevo todavía puede ejecutar una aplicación enlazada con un libcurl más antiguo, o un cliente que use una biblioteca completamente distinta. La versión del sistema operativo no es un inventario completo de clientes.
Para cada consumidor, registre su interfaz de configuración admitida y la expresión más pequeña de las rutas previstas. Una lista corta y explícita de hosts puede ser mejor que un patrón ingenioso cuyo significado nadie puede explicar.
Mantenga la evidencia de configuración separada de la evidencia de conexión
Una configuración analizada o una API de decisiones de enrutamiento puede mostrar qué seleccionó el programa. El resultado de una solicitud muestra después si esa ruta era utilizable. En .NET, HttpClient.DefaultProxy.IsBypassed proporciona esa comprobación del lado de la configuración cuando el proxy predeterminado es la política en uso. No diagnostique un servicio directo inalcanzable como un fallo del analizador de omisión solo porque la solicitud agotó el tiempo de espera.
Conserve los destinos límite al actualizar un cliente o una imagen base. Hacen visibles los cambios futuros de compatibilidad sin que todo el equipo tenga que redescubrir por qué el archivo contiene dos entradas de dominio parecidas.