A Ping nem bizonyíték: tesztelje a két telephely közötti útvonalat
Az átjáróról indított ping semmit sem mond a szolgáltatásról. Járja végig az útvonalat valódi kliensről, használja az alkalmazás protokollját, és reprodukálja a méretet vagy nevet, amely meghiúsul.
Az alagút él, az átjárók válaszolnak egymásnak, és az egyik telephely felhasználói mégsem tudják megnyitni a másik fájlmegosztását. Valaki pingel az átjáróról, választ kap, és egészségesnek nyilvánítja a hálózatot. Az a válasz két olyan eszköz között utazott, amely soha nem volt a probléma. Egy hasznos teszt annál a gazdagépnél kezdődik, amelynek szolgáltatásra van szüksége, azt a protokollt használja, amelyet az alkalmazás használ, és reprodukálja azt a feltételt, amelyben meghiúsul. Minden más zöld jelzés egy olyan útvonalra, amelyen nincs senki.
Kezdje annál a kliensnél, amelynek szolgáltatásra van szüksége
Írjon le négy dolgot, mielőtt bármit tesztel: a kliens címét, a célcímét, a gazdagép nevét és az alkalmazás portját. Ezután erősítse meg, hogy a szolgáltatás helyben, a saját telephelyén működik, egy mellette lévő gazdagépről. Ezen alapvonal nélkül nem tudja megkülönböztetni a törött alagutat a törött szolgáltatástól, és ezeknek a jegyeknek a fele az utóbbi.
Próbálja ki a dokumentált gazdagépnevet és, ahol a szolgáltatás engedi, ugyanazon port közvetlen címellenőrzését. A sikertelen névkeresés és az elérhetetlen feloldott cím különböző utakra viszi. Ha egy gazdagépnevet IP-címre cserél, ne kapcsolja ki az HTTPS-identitásellenőrzést, hogy működjön; a tanúsítványfigyelmeztetés információ, nem akadály.
Járja végig az útvonalat minden peremen
Olvassa el az útvonalat, amelyet a kliens választ, majd azt, amelyet az átjáró választ ehhez a célhoz, majd a számlálókat vagy egy korlátozott rögzítést minden peremen. Két tényt keres: megérkezett-e a kérés a távoli helyi hálózatra, és visszajött-e válasz. Az interfész-számlálók minden más folyamatot tartalmaznak, ezért pontos időbélyeg és cím-pár szerint korreláljon, ne a grafikon alakja szerint. A rossz peremen vett rögzítés rosszabb, mint a semmi, mert bizonyítéknak látszik.
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
Ha a kérés megjelenik a távoli peremen anélkül, hogy válasz lenne mögötte, a probléma a túloldalon van: tűzfal, hiányzó visszaútvonal vagy olyan gazdagép, amely nem fogadja el a forrást. Ha a kérés soha nem jelenik meg, a helyi útvonal vagy az alagút szelektorai nem szállították, és a túloldal még nem érdemes vizsgálatra.
Használja azt a protokollt, amelyet az alkalmazás használ
Az ICMP gyenge próba. Szűrhető, sebességkorlátozható vagy a szolgáltatástól eltérő házirenddel kezelhető, ami sikerét és kudarcát egyaránt kétértelművé teszi. Tesztelje a tényleges portot és, ahol lehet, a tényleges protokoll-kézfogást.
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
A befejezett TCP-kézfogás bizonyítja az elérhetőséget és a házirendet ehhez a porthoz. Nem bizonyítja, hogy az alkalmazás működik: a hitelesítés, egy feltöltés vagy egy adott API-hívás továbbra is meghiúsulhat. Tesztelje azt a műveletet, amelyet a felhasználók valóban végrehajtanak, ártalmatlan megfelelővel a valódi tranzakció ismételt beküldése helyett.
Reprodukálja a feltételt, amelyben meghiúsul
A csak nagy átvitelnél jelentkező hibák méretproblémák, nem kapcsolódási problémák. Küldjön nagy csomagot beállított don't-fragment bittel, és figyelje, hol áll meg. Ha egy kis kérés sikerül és egy nagy elakad, az alagút MTU-ja és az átjárók MSS-kezelése a következő gyanúsítottak.
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
Ha csak egy alhálózat hiúsul meg, nézze a forgalomszelektorokat, az útvonalhirdetéseket és annak az alhálózatnak a visszaátjáróját. Ha csak a gazdagépnév hiúsul meg, kövesse a DNS-t, beleértve azt, hogy melyik feloldót használta a kliens, és hogy a távoli nézet látható-e arról a telephelyről. Három különböző hiba, három különböző javítás, és a ping teszt egyiket sem különbözteti meg.
A javítás után ismételje meg ugyanazt a tesztet
Futtassa újra ugyanazt a klienst, célt, portot és hasznos terhet. Ezután csatlakozzon újra, vagy gyakorolja a tartalék útvonalat, ha a tervezésnek van ilyen, mert az a javítás, amely csak addig működik, amíg az eredeti alagútpéldány él, nincs tesztelve. Tartsa a tesztet valódi forráshoz, valódi célhoz és valódi művelethez kötve, ne egyetlen zöld jelzőhöz egy irányítópulton.
Rögzítse a négy alapértéket és az eredményt. A következő jelentés ugyanarról a tünetről aztán bizonyítékokból indulhat ki, nem pingből.