Kateri NAT skok izgubi nedejavno preslikavo VPN in kako to ugotoviti
Nedejaven tok VPN lahko umre na vsakem skoku, ki hrani stanje. Ponovite en test, primerjajte, kaj je videla vsaka meja, in poročajte o omejenem rezultatu namesto o ugibanem krivcu.
Po mirnem obdobju se tunel znova poveže, noben dnevnik ne imenuje krivca, in očitna poteza je izbrati napravo z najbolj impresivno dokumentacijo časovne omejitve. To je ugibanje, preoblečeno v diagnozo. Stanje lahko nekaj časa preživi v domačem usmerjevalniku, v operaterjevem prevajalniku in na robu oblaka, in vsak od njih lahko izpusti tok, ki utihne. Namesto tega lahko preslikate pot, označite, katere naprave lahko resnično opazujete, in izvedete en nedejaven test, ki ga lahko ponovite.
Ponovljiv test spremeni anekdoto v meritev. Vse spodaj predpostavlja enega odjemalca, en strežnik in en protokol ter predpostavlja, da se upirate spreminjanju dveh spremenljivk hkrati. Cilj je narediti naslednji dogodek cenejši od tega.
Vsakič izvedite isti nedejavni test
Zapišite, kdaj je bil tok nazadnje v redu, kako dolgo je bil nato nedejaven in ali ga je en svež paket vrnil. Ta tri dejstva so meritev; brez njih imate zgodbo o prenosniku, ki je padel. Pri vsaki ponovitvi uporabite istega odjemalca, isti strežnik in isti protokol ter zabeležite trenutek, ko je bil po tišini poslan prvi paket.
Nato primerjajte, kaj je v resnici videla vsaka meja, ki je vaša. Preiskavo odloči razlika, ali strežnik po premoru ni videl prav ničesar ali je videl zahtevo in odgovoril v pot, ki odgovorov ni več nosila.
| 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 |
Primerjanje poti brez spreminjanja petih stvari
Drugo odobreno dostopovno omrežje je legitimna primerjava, ker se veriga NAT razlikuje. Razlikuje se tudi po ponudniku, radijskih razmerah in morda družini naslovov, zato je rezultat meja in ne pripis. Omejitve zabeležite skupaj z rezultatom, namesto da bi jih pri poročanju tiho izpustili. Zapišite tudi pot: naprava, vloga in ali je njeno stanje sploh mogoče prebrati.
Primerjava poti vam kupi omejeno vprašanje: tok preživi na eni in umre na drugi po podobni tišini, zato spremenljivka živi nekje v delih, ki se razlikujejo. To je resničen rezultat, tudi ko ni imenovana nobena naprava, in naslednjemu inženirju pove, kje naj preživi popoldne in kje ne.
Lokalno stanje je vredno prebrati, preden ugibate o operaterjih. Na prehodu Linux conntrack -L navaja sledene tokove s preostalo življenjsko dobo, kar ugibanje o časovniku spremeni v število, ki mu lahko gledate, kako poteče. Preberite ga pred obdobjem nedejavnosti in po njem, ne samo po.
Kaj bo zadržal signal za ohranjanje in kaj ne
Podprt signal za ohranjanje drži preslikavo odprto, odprta preslikava pa ne dokazuje ničesar o storitvi za njo. Tunel lahko ostane preslikan, medtem ko je aplikacija, ki jo prenaša, že prenehala odgovarjati, in z vidika statusne lučke sta ti dve situaciji videti enaki. Signal za ohranjanje obravnavajte kot zavarovanje pred potekom zaradi nedejavnosti, ne kot preverjanje zdravja.
Interval nastavite glede na najkrajšo časovno omejitev, ki ste jo resnično izmerili, ne glede na število, prepisano s foruma. Signal za ohranjanje, nastavljen pod vsakim možnim časovnikom, je promet, ki ga nihče ni potreboval, in odstrani tudi simptom, ki bi vam povedal, katera meja poteče prva. Interval izberite iz izmerjenega števila in vse drugo pustite pri miru.
Ena sprememba, nato znova izmerite
Upirajte se želji, da bi med živim testom dvignili vsako časovno omejitev in izpraznili vsak prehod. To izbriše dokaze, po katere ste prišli, in prekine tokove drugih ljudi, kar je slaba menjava za nepreverjeno hipotezo. Spremenite eno podprto nastavitev na eni napravi, nato ponovite obdobje nedejavnosti in obnovitev aplikacije.
Zabeležite, katero opazovanje meje se je premaknilo, in to tudi takrat, ko se ni nič izboljšalo. Nastavitev, ki ni ničesar popravila, je informacija, in ceneje je to opaziti enkrat, kot to prevoziti po celem posestvu.
Napisati ugotovitev, ki jo lahko branite
Ko prevajalnika višje po poti ni mogoče pregledati, povejte le, kar dokazi podpirajo: izmenjava umre nekje na tem odseku poti po toliko tišine, odgovorni skok pa ostane nepripisan. Omejena trditev prestane pregled in naslednjo osebo usmeri na pravi segment. Imenovanje skritega usmerjevalnika za vzrok ne naredi ne enega ne drugega. Omejeno ugotovitev predajte tistemu, ki ima neopazovani segment, z intervalom priloženim.
RFC 4787 opisuje, zakaj je časovnike preslikave UDP težko sklepati z enega konca, in prav ta težava naredi omejeno ugotovitev pošteno. Časovniki so resnični, in negotovost okoli njih tudi.