Ping är inte bevis: testa vägen mellan två platser

En ping från gatewayen säger ingenting om tjänsten. Gå vägen från en riktig klient, använd protokollet som appen använder och återskapa storleken eller namnet som misslyckas.

Tunneln är uppe, gatewayerna svarar varandra, och användarna på den ena platsen kan fortfarande inte öppna filutdelningen på den andra. Någon pingar från gatewayen, får ett svar och förklarar nätet friskt. Svaret reste mellan två enheter som aldrig var problemet. Ett användbart test börjar på värden som behöver tjänsten, använder protokollet som applikationen använder och återskapar villkoret som det misslyckas under. Allt annat är grönt ljus för en väg som ingen är på.

Börja vid klienten som behöver tjänsten

Skriv ner fyra saker innan du testar något: klientadressen, destinationsadressen, värdnamnet och applikationens port. Bekräfta sedan att tjänsten fungerar lokalt på sin egen plats, från en värd bredvid. Utan den baslinjen kan du inte skilja en trasig tunnel från en trasig tjänst, och hälften av dessa ärenden är det andra.

Prova det dokumenterade värdnamnet och, där tjänsten tillåter det, en direkt adresskontroll av samma port. En misslyckad namnsökning och en oåtkomlig upplöst adress leder dig längs olika vägar. Om du byter ut ett värdnamn mot en IP, stäng inte av HTTPS-identitetskontrollen för att få det att fungera; en certifikatvarning är information, inte ett hinder.

Gå vägen vid varje kant

Läs rutten som klienten väljer, sedan rutten som gatewayen väljer för den destinationen, sedan räknarna eller en avgränsad fångst vid varje kant. Du letar efter två fakta: nådde begäran det fjärran LAN:et, och kom ett svar tillbaka. Gränssnittsräknare omfattar varje annat flöde, så korrelera efter exakt tidsstämpel och adresspar i stället för grafens form. En fångst tagen vid fel kant är värre än ingen, eftersom den ser ut som bevis.

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

Om begäran dyker upp vid den fjärran kanten utan ett svar bakom, är problemet på andra sidan: en brandvägg, en saknad returväg eller en värd som inte accepterar källan. Om begäran aldrig dyker upp har den lokala rutten eller tunnelväljarna inte burit den, och andra sidan är ännu inte värd att undersöka.

Använd protokollet som applikationen använder

ICMP är en svag sond. Den kan filtreras, hastighetsbegränsas eller hanteras av en annan policy än tjänsten, vilket gör både framgången och misslyckandet tvetydigt. Testa den faktiska porten och, där du kan, det faktiska protokollhandskakningen.

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

Ett slutfört TCP-handskakning bevisar nåbarhet och policy för den porten. Det bevisar inte att applikationen fungerar: autentisering, en uppladdning eller ett visst API-anrop kan fortfarande misslyckas. Testa operationen som användarna faktiskt utför, med en ofarlig motsvarighet i stället för att upprepat skicka en riktig transaktion.

Återskapa villkoret som misslyckas

Fel som bara visar sig vid stora överföringar är ett storleksproblem, inte ett anslutningsproblem. Skicka ett stort paket med don't-fragment-biten satt och se var det stannar. Om en liten begäran lyckas och en stor hänger sig, är tunnelns MTU och MSS-hanteringen på gatewayerna nästa misstänkta.

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

Om bara ett subnät misslyckas, titta på trafikväljare, ruttannonseringar och det subnätets returgateway. Om bara värdnamnet misslyckas, följ DNS, inklusive vilken resolver klienten använde och om fjärrvyn är synlig från den platsen. Tre olika fel, tre olika åtgärder, och pingtestet skiljer inte ut något av dem.

Efter åtgärden, upprepa samma test

Kör samma klient, destination, port och nyttolast igen. Anslut sedan igen eller prova redundansvägen om designen har en, eftersom en åtgärd som bara fungerar så länge den ursprungliga tunnelinstansen lever inte har testats. Håll testet knutet till en riktig källa, en riktig destination och en riktig operation i stället för en grön indikator på en instrumentpanel.

Notera de fyra basvärdena och resultatet. Nästa rapport om samma symptom kan då börja med bevis i stället för med en ping.

Relaterade artiklar