Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. Networking


Resolve networking issues including subnet conflicts and SSL/TLS certificate problems.

7.1. Issue - Container subnet conflicts with internal network

The default subnet used in Ansible Automation Platform containers conflicts with the internal network resulting in "No route to host" errors.

To resolve this issue, update the default classless inter-domain routing (CIDR) value so it does not conflict with the CIDR used by the default Podman networking plugin.

Procedure

  1. In all controller and hybrid nodes, run the following commands to create a file called custom.py:

    # touch /etc/tower/conf.d/custom.py
    # chmod 640 /etc/tower/conf.d/custom.py
    # chown root:awx /etc/tower/conf.d/custom.py
  2. Add the following to the /etc/tower/conf.d/custom.py file:

    DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.168.1.0/24']
    • 192.168.1.0/24 is the value for the new CIDR in this example.
  3. Stop and start the automation controller service in all controller and hybrid nodes:

    # automation-controller-service stop
    # automation-controller-service start

    All containers will start on the new CIDR.

7.2. Troubleshooting SSL/TLS issues

To troubleshoot SSL/TLS issues, verify the certificate chain, use the correct certificates, and confirm that a trusted Certificate Authority (CA) signed the certificate.

Procedure

  1. Check if the server is reachable over SSL/TLS.

    1. Run the following command to confirm whether the server is reachable over SSL/TLS and to see the full certificate chain:

      # true | openssl s_client -showcerts -connect <fqdn_or_ip>:<port>
    2. Replace <fqdn_or_ip> and <port> with suitable values.
  2. Verify the certificate details.

    1. Run the following command to view the details of a certificate:

      # openssl x509 -in <path_to_certificate> -noout -text
  3. Replace <path_to_certificate> with the path to the certificate file you want to inspect.

    The result of the command shows information such as:

    • Subject - The entity the certificate has been issued to.
    • Issuer - The CA that issued the certificate.
    • Validity "Not Before" - The date the certificate was issued.
    • Validity "Not After" - The date the certificate expires.
  4. Verify a trusted CA signed the certificate.

    1. Run the following command to verify that a specific certificate is valid and was signed by a trusted CA:

      openssl verify -CAfile <path_to_ca_public_certificate> <path_to_server_certificate_file_to_verify>
    2. If the command returns OK, it means the certificate file is valid and signed by a trusted CA.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red Hat
Retour au début