Melyik NAT-ugrás dobja el az inaktív VPN-leképezést, és hogyan deríthető ki
Egy inaktív VPN-folyam bármely állapottartó ugrásnál meghalhat. Ismételjen meg egy tesztet, hasonlítsa össze, mit látott minden határ, és a találgatott bűnös helyett a korlátozott eredményt jelentse.
Egy csendes időszak után az alagút újracsatlakozik, egyetlen napló sem nevez meg bűnöst, és a kézenfekvő lépés a leglenyűgözőbb időtúllépés-dokumentációval rendelkező eszköz kiválasztása. Ez diagnózisnak álcázott találgatás. Az állapot egy ideig túlélhet egy otthoni routerben, egy szolgáltatói fordítóban és egy felhőperemen, és bármelyikük eldobhat egy folyamot, amely elcsendesedik. Ehelyett feltérképezheti az útvonalat, megjelölheti, mely eszközöket tudja valóban megfigyelni, és lefuttathat egy inaktív tesztet, amelyet meg tud ismételni.
Az ismételhető teszt anekdotát méréssé alakít. Az alábbiak mind egy klienst, egy szervert és egy protokollt feltételeznek, és feltételezik, hogy ellenáll annak, hogy egyszerre két változót módosítson. A cél, hogy a következő eset olcsóbb legyen, mint ez.
Minden alkalommal ugyanazt az inaktív tesztet futtassa
Jegyezze fel, mikor volt a folyam utoljára rendben, mennyi ideig ült utána inaktívan, és hogy egy friss csomag visszahozta-e. Ez a három tény a mérés; nélkülük csak egy leesett laptopról szóló története van. Minden ismétlésnél ugyanazt a klienst, ugyanazt a szervert és ugyanazt a protokollt használja, és jegyezze fel azt a pillanatot, amikor a csend után az első csomag elment.
Ezután hasonlítsa össze, mit látott valójában minden határ, amely az Öné. A vizsgálatot eldöntő különbség az, hogy a szerver semmit sem látott a szünet után, vagy látta a kérést és olyan útvonalba válaszolt, amely már nem vitte a válaszokat.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Útvonalak összehasonlítása öt dolog megváltoztatása nélkül
Egy második jóváhagyott hozzáférési hálózat legitim összehasonlítás, mert a NAT-lánc eltér. Szolgáltatóban, rádiós viszonyokban és esetleg címcsaládban is eltér, így az eredmény határ, nem pedig tulajdonítás. A jelentéskor ne hallgassa el a korlátozásokat, hanem rögzítse őket az eredménnyel együtt. Írja le az útvonalat is: eszköz, szerep, és hogy olvasható-e egyáltalán az állapota.
Az útvonalak összehasonlítása korlátozott kérdést ad: a folyam az egyiken túlél, a másikon hasonló csend után meghal, tehát a változó valahol az eltérő részekben van. Ez akkor is valódi eredmény, ha egyetlen eszközt sem nevez meg, és megmondja a következő mérnöknek, hol töltsön el egy délutánt és hol ne.
Érdemes kiolvasni a helyi állapotot, mielőtt a szolgáltatókról spekulálna. Egy Linux-átjárón a conntrack -L listázza a követett folyamokat a hátralévő élettartamukkal, ami az időzítőről szóló találgatást olyan számmá alakítja, amelyet nézhet lejárni. Olvassa ki az inaktív időszak előtt és után, ne csak utána.
Mit tart meg az életben tartó jelzés és mit nem
Egy támogatott életben tartó jelzés nyitva tartja a leképezést, és a nyitva tartott leképezés semmit sem bizonyít a mögötte lévő szolgáltatásról. Az alagút leképezve maradhat, miközben a rajta utazó alkalmazás már nem válaszol, és állapotfény szempontjából ez a két helyzet ugyanúgy néz ki. Az életben tartó jelzést az inaktív lejárat elleni biztosításként kezelje, ne állapotellenőrzésként.
Az intervallumot a ténylegesen mért legrövidebb időtúllépéshez állítsa, ne egy fórumból másolt számhoz. Minden elképzelhető időzítő alá hangolt életben tartó jelzés olyan forgalom, amelyre senkinek nem volt szüksége, és eltünteti azt a tünetet is, amely megmondta volna, melyik határ jár le először. A mért számból válassza ki az intervallumot, és hagyjon minden mást békén.
Egy változtatás, aztán mérjen újra
Ellenálljon a késztetésnek, hogy egy élő teszt alatt minden időtúllépést megemeljen és minden átjárót kiürítsen. Ez eltörli a bizonyítékokat, amelyekért jött, és mások folyamait szakítja meg, ami rossz üzlet egy ki nem próbált hipotézisért. Módosítson egy támogatott beállítást egyetlen eszközön, majd ismételje meg az inaktív időszakot és az alkalmazás helyreállását.
Jegyezze fel, melyik határmegfigyelés mozdult el, és akkor is jegyezze fel, amikor semmi sem javult. A beállítás, amely semmit sem javított, információ, és olcsóbb egyszer észrevenni, mint végigvinni az egész állományon.
Olyan megállapítás írása, amelyet meg tud védeni
Amikor egy felsőbb fordító nem vizsgálható, csak azt mondja, amit a bizonyítékok alátámasztanak: a csere valahol ezen az útvonalszakaszon meghal ennyi csend után, és a felelős ugrás azonosítatlan marad. A korlátozott állítás átvészeli a felülvizsgálatot, és a megfelelő szegmensre irányítja a következő embert. Egy rejtett router okként való megnevezése egyiket sem teszi meg. Adja át a korlátozott megállapítást annak, aki a nem megfigyelhető szegmenssel rendelkezik, az intervallumot mellékelve.
RFC 4787 leírja, miért nehéz az UDP-leképezés időzítőit egyetlen végpontból kikövetkeztetni, és éppen ez a nehézség teszi a korlátozott megállapítást őszintévé. Az időzítők valósak, és a körülöttük lévő bizonytalanság is.