Menu
Comprendre F5 · LTM

F5 : diagnostiquer une application HTTP ou HTTPS inaccessible

Comparer accès direct et accès VIP, conserver Host et SNI et séparer panne TCP, handshake TLS, réponse HTTP et persistance.

Thomas SAUTIER · Publié le · Dépannage

Références et objectifs de certification (7)
  • Certification : F5 301A · Référence consultée le · Objectifs abordés : F5 301A 1.08.
  • Certification : F5 301B · Référence consultée le · Objectifs abordés : F5 301B 2.06, F5 301B 2.07, F5 301B 2.08, F5 301B 2.09, F5 301B 2.11, F5 301B 2.12.
  • Certification : 201 · Référence consultée le · Objectifs abordés : 201 1.03.
  • Certification : 401 · Référence consultée le · Objectifs abordés : 401 3.06.
  • Certification : F5CAB5 · Référence consultée le · Objectifs abordés : F5CAB5 F5CAB5.04.
  • Certification : F5CABR · Référence consultée le · Objectifs abordés : F5CABR 5.04.
  • Certification : F5CTSLTMR · Référence consultée le · Objectifs abordés : F5CTSLTMR 5.01, F5CTSLTMR 5.02, F5CTSLTMR 5.03, F5CTSLTMR 5.04, F5CTSLTMR 6.01, F5CTSLTMR 6.02, F5CTSLTMR 6.03, F5CTSLTMR 6.04.

Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.

Comprendre en imageDépannage HTTPS : localiser la première étape qui échoue
Dépannage HTTPS : localiser la première étape qui échoue Vérifier successivement résolution, connexion TCP, négociation TLS et échange HTTP. Le backend ajoute son propre chemin et éventuellement son propre TLS. Comparer un test normal et un test vers l’IP imposée en conservant le nom aide à isoler la différence. Oui Non Nom et arrivée sur la VIP Résolution DNS attendueAdresse, port et VS correctsArrivée du trafic au bon point Transport et TLS Connexion TCPHandshake et certificat du côté concernéClient SSL et Server SSL examinésséparément HTTP et application Host, URI, en-têtes et authentificationRéponse BIG-IP ou backendIdentité du composant qui produit l’erreur HTTP reçu ? Interpréter le résultat HTTP 404 : une réponse HTTP existeComparer Host, chemin et backendIdentifier l’émetteur avant de modifier Revenir au premier échec DNS, arrivée, TCP ou TLSCorréler captures et erreursÉviter les changements multiples àl’aveugle Objets et conditions Le dessin est une méthode de localisation, pas uneclassification exhaustive des erreurs. Une réponseHTTP ne valide ni l’URL métier ni l’autorisation. Comparer sonde et requête utilisateur Le moniteur peut employer une autre URL, un autre Host ou des paramètres TLS différents. Son succès n’explique pas à luiseul un échec utilisateur.

Vérifier successivement résolution, connexion TCP, négociation TLS et échange HTTP. Le backend ajoute son propre chemin et éventuellement son propre TLS. Comparer un test normal et un test vers l’IP imposée en conservant le nom aide à isoler la différence.

Télécharger le schéma en SVG · version claire

Séparer les étapes de l’échange

Commencez par résolution du nom, arrivée sur la VIP et établissement TCP. Examinez ensuite TLS, puis HTTP. Une réponse 404 prouve qu’une réponse HTTP a été produite ; elle ne décrit pas une absence totale de connectivité.

Un moniteur vert ne prouve pas que votre URL, votre Host ou votre authentification fonctionne. Les requêtes du moniteur et de l’utilisateur peuvent prendre des chemins applicatifs différents.

Sources : F5, ltm monitor http ; F5, ltm virtual.

Tester une IP sans perdre le nom de l’application

Accéder à une adresse IP peut changer le SNI TLS et l’en-tête Host. Pour comparer la VIP et un backend, conservez le nom attendu avec l’option resolve de curl. Dans cet exemple pédagogique, les deux destinations sont des adresses de documentation et écoutent en HTTPS sur 443.

Comprendre en imageDeux tests qui conservent le nom applicatif
Deux tests qui conservent le nom applicatif Un test normal suit la résolution DNS habituelle. Un test curl --resolve impose l’adresse cible tout en conservant le nom dans l’URL, donc le Host et le SNI pour HTTPS. Une différence de résultat doit être interprétée en tenant compte des autres conditions du test. Objets, conditions et comparaisons du guide URL HTTPS app.example.test Résolution Adresse obtenue par DNS Test normal Chemin habituel Même URL HTTPS app.example.test curl --resolve Adresse cible imposée Test ciblé Host et SNI conservés Séparer les étapes de l’échange Commencez par résolution du nom, arrivée sur laVIP et établissement TCP. Examinez ensuite TLS,puis HTTP. Une réponse 404 prouve qu’uneréponse HTTP a été produite ; elle ne décrit pasune absence totale de connectivité. Tester une IP sans perdre le nom del’application Accéder à une adresse IP peut changer le SNI TLSet l’en-tête Host. Pour comparer la VIP et unbackend, conservez le nom attendu avec l’optionresolve de curl. Dans cet exemple pédagogique,les deux destinations sont des adresses dedocumentation et écoutent en HTTPS sur 443.

Un test normal suit la résolution DNS habituelle. Un test curl --resolve impose l’adresse cible tout en conservant le nom dans l’URL, donc le Host et le SNI pour HTTPS. Une différence de résultat doit être interprétée en tenant compte des autres conditions du test.

Télécharger le schéma en SVG · version claire
Comparer VIP et backend avec le même nomShell · requêtes HTTP de diagnostic
curl --verbose --resolve app.example.invalid:443:192.0.2.40 \
  https://app.example.invalid/health

curl --verbose --resolve app.example.invalid:443:192.0.2.60 \
  https://app.example.invalid/health

Sources : Projet curl, curl man page.

Comparer ce qui change entre les deux essais

Comparez code de réponse, Location, cookies, chaîne de certificat et délai. Si l’essai backend utilise un autre port ou HTTP clair après offload, adaptez explicitement le scénario : vous ne comparez plus deux échanges identiques.

Le backend peut n’accepter que BIG-IP ou exiger une authentification différente. Un accès direct refusé dans ce cas n’établit pas que le serveur est en panne. Conservez la description des conditions de test.

Sources : Projet curl, curl man page ; F5, ltm profile server-ssl.

Identifier le côté où le handshake échoue

Un profil Client SSL peut échouer avec le client, tandis que Server SSL peut échouer avec le backend après l’acceptation côté client. Examinez versions, suites, nom, chaîne, expiration et demande de certificat du pair concerné.

Évitez de masquer une erreur de validation pour déclarer le service correct. Le guide certificats, SNI et mTLS propose les points à vérifier, et le guide modes TLS situe les terminaisons.

Sources : Projet OpenSSL, openssl s_client ; F5, ltm profile client-ssl ; F5, ltm profile server-ssl.

Lire les messages et la session

Les redirections répétées peuvent révéler une incohérence de schéma ou de nom vue par l’application. Des pertes de session peuvent venir d’un cookie, d’une affinité ou d’un état serveur. Un 403 peut être produit par plusieurs composants ; identifiez la réponse et le chemin avant de modifier une autorisation.

Pour un problème intermittent, relevez le membre qui répond à chaque tentative. Une différence entre membres peut être plus révélatrice qu’une statistique moyenne du VS.

Sources : F5, ltm profile http ; F5, ltm persistence cookie ; F5, ltm profile analytics.

Une collecte minimale utile

Notez heure UTC, client, URL, méthode, nom TLS, membre et résultat. Ajoutez configuration du VS, profils nécessaires et une capture bornée sur chaque côté. Distinguez les faits observés des hypothèses ; vérifiez une hypothèse par une comparaison ciblée avant de corriger.

Sources : F5, Packet tracing with tcpdump ; F5, sys log.

Décoder un corps POST selon son Content-Type

Une méthode POST ne décrit pas le format du corps. application/x-www-form-urlencoded utilise des paires encodées ; le signe + peut représenter un espace. JSON possède une structure et un encodage propres. Multipart contient des boundaries et peut porter des fichiers : lui appliquer le décodage d’un formulaire simple produit une interprétation incorrecte.

Pour lire un exemple, partez de Content-Type et Content-Length ou du framing chunked. Comparez les octets reçus et les valeurs obtenues par le parseur prévu. Ne décodez pas récursivement toutes les valeurs sans comprendre le contrat : un deuxième décodage peut changer le sens d’une chaîne légitime.

Dans une iRule, HTTP_REQUEST donne accès aux en-têtes, pas automatiquement à tout le corps. HTTP::collect permet une collecte bornée et HTTP_REQUEST_DATA permet d’examiner les données collectées avec HTTP::payload. Plusieurs collect concurrents et une collecte après réponse peuvent provoquer des erreurs. Cet exemple Python explique le décodage d’un formulaire fictif, sans installer une collecte sur le BIG-IP.

Décodage local d’un formulaire fictifRésultats attendus : revision F5 et /api/orders. Ne pas utiliser des credentials réels.
from urllib.parse import parse_qs

body = "name=Samhan&note=revision+F5&path=%2Fapi%2Forders"
values = parse_qs(body, keep_blank_values=True)
print(values["note"][0])
print(values["path"][0])

Sources : F5, HTTP::collect ; F5, HTTP::payload ; F5, URI::decode ; F5, ltm profile http.

Sources et portée

Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 LTM

Continuer la série F5

Explorer tous les guides du parcours F5 LTM

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et vos services applicatifs.

Parler de votre projet