Ping is geen bewijs: test het pad tussen twee locaties

De tunnel staat, de gateways antwoorden elkaar, en de gebruikers op de ene locatie kunnen de bestandsshare op de andere nog steeds niet openen. Iemand pingt vanaf de gateway, krijgt antwoord en verklaart het netwerk gezond. Dat antwoord reisde tussen twee apparaten die nooit het probleem waren. Een bruikbare test begint op de host die de dienst nodig heeft, gebruikt het protocol dat de applicatie gebruikt en reproduceert de omstandigheid waarin het faalt. Al het andere is groen licht voor een pad waar niemand op zit.

Begin bij de client die de dienst nodig heeft

Schrijf vier dingen op voordat je iets test: het clientadres, het bestemmingsadres, de hostnaam en de poort van de applicatie. Bevestig daarna dat de dienst lokaal op zijn eigen locatie werkt, vanaf een host ernaast. Zonder die basislijn kun je een kapotte tunnel niet van een kapotte dienst onderscheiden, en de helft van deze tickets is het tweede geval.

Probeer de gedocumenteerde hostnaam en, waar de dienst het toestaat, een directe adrescontrole van dezelfde poort. Een mislukte naamopzoeking en een onbereikbaar opgelost adres sturen je langs verschillende paden. Als je een hostnaam door een IP vervangt, schakel dan de HTTPS-identiteitscontrole niet uit om het werkend te krijgen; een certificaatwaarschuwing is informatie, geen obstakel.

Loop het pad bij elke rand

Lees de route die de client kiest, dan de route die de gateway voor die bestemming kiest, dan de tellers of een beperkte opname bij elke rand. Je zoekt twee feiten: kwam het verzoek aan op het externe LAN, en kwam er een antwoord terug. Interfacetellers bevatten elke andere stroom, dus correleer op exacte tijdstempel en adrespaar in plaats van op de vorm van de grafiek. Een opname aan de verkeerde rand is erger dan geen, omdat het op bewijs lijkt.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Als het verzoek aan de externe rand verschijnt zonder antwoord erachter, ligt het probleem aan de andere kant: een firewall, een ontbrekende retourroute of een host die de bron niet accepteert. Als het verzoek nooit verschijnt, hebben de lokale route of de tunnelselectors het niet gedragen, en de andere kant is nog geen onderzoek waard.

Gebruik het protocol dat de applicatie gebruikt

ICMP is een zwakke sonde. Het kan worden gefilterd, snelheidsbeperkt of door een ander beleid dan de dienst worden behandeld, waardoor zowel het succes als het falen dubbelzinnig is. Test de werkelijke poort en, waar je kunt, de werkelijke protocolhandshake.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Een voltooide TCP-handshake bewijst bereikbaarheid en beleid voor die poort. Het bewijst niet dat de applicatie werkt: authenticatie, een upload of een specifieke API-aanroep kan nog steeds falen. Test de handeling die gebruikers werkelijk uitvoeren, met een onschadelijk equivalent in plaats van herhaaldelijk een echte transactie in te dienen.

Reproduceer de omstandigheid die faalt

Fouten die alleen bij grote overdrachten verschijnen zijn een grootteprobleem, geen connectiviteitsprobleem. Stuur een groot pakket met de don't-fragment-bit gezet en kijk waar het stopt. Als een klein verzoek slaagt en een groot blijft hangen, zijn de tunnel-MTU en de MSS-behandeling op de gateways de volgende verdachten.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Als slechts één subnet faalt, kijk naar traffic selectors, routeaankondigingen en de retourgateway van dat subnet. Als alleen de hostnaam faalt, volg DNS, inclusief welke resolver de client gebruikte en of de externe weergave vanaf die locatie zichtbaar is. Drie verschillende storingen, drie verschillende oplossingen, en de pingtest onderscheidt er geen enkele.

Herhaal na de correctie dezelfde test

Voer dezelfde client, bestemming, poort en payload opnieuw uit. Maak daarna opnieuw verbinding of test het failover-pad als het ontwerp er een heeft, want een correctie die alleen werkt zolang de oorspronkelijke tunnelinstantie leeft, is niet getest. Houd de test gekoppeld aan een echte bron, een echte bestemming en een echte handeling in plaats van aan één groene indicator op een dashboard.

Noteer de vier basiswaarden en het resultaat. Het volgende rapport over hetzelfde symptoom kan dan met bewijs beginnen in plaats van met een ping.