Watter NAT-hop laat die onaktiewe VPN-kaartering val, en hoe om dit te bepaal
’n Onaktiewe VPN-vloei kan by enige toestandhoudende hop sterf. Herhaal een toets, vergelyk wat elke grens gesien het, en rapporteer die begrensde resultaat eerder as ’n gerate skuldige.
Ná ’n stil tydperk herverbind die tonnel, niks in enige log noem ’n skuldige nie, en die ooglopende stap is om die toestel te kies met die indrukwekkendste dokumentasie oor tydsverloop. Dit is ’n raaiskoot wat as ’n diagnose vermom is. Toestand kan ’n ruk lank in ’n huisroeteerder, in ’n vervoerder-omsetter en by ’n wolkrand oorleef, en enigeen van hulle kan ’n vloei laat val wat stil raak. Wat jy eerder kan doen, is om die pad te karteer, te merk watter toestelle jy werklik kan waarneem, en een onaktiewe toets uit te voer wat jy kan herhaal.
’n Herhaalbare toets verander ’n staaltjie in ’n meting. Alles hieronder veronderstel een kliënt, een bediener en een protokol, en dit veronderstel dat jy weerstaan om twee veranderlikes gelyktydig te verander. Die punt is om die volgende gebeurtenis goedkoper te maak as hierdie een.
Voer elke keer dieselfde onaktiewe toets uit
Skryf neer wanneer die vloei laas bekend goed was, hoe lank dit daarna stil gesit het, en of een vars pakkie dit teruggebring het. Daardie drie feite is die meting; sonder hulle het jy ’n verhaal oor ’n skootrekenaar wat geval het. Gebruik dieselfde kliënt, dieselfde bediener en dieselfde protokol by elke herhaling, en let op die oomblik toe die eerste pakkie ná die stilte gestuur is.
Vergelyk dan wat elke grens wat jy besit werklik gesien het. Die onderskeid wat die ondersoek beslis, is of die bediener glad niks ná die pouse gesien het nie, of die versoek gesien en geantwoord het in ’n pad wat die antwoorde nie meer gedra het nie.
| 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 |
Om paaie te vergelyk sonder om vyf dinge te verander
’n Tweede goedgekeurde toegangsnetwerk is ’n geldige vergelyking, want die NAT-ketting verskil. Dit verskil ook in diensverskaffer, radiografiese toestande en moontlik adresfamilie, so die resultaat is ’n grens eerder as ’n toeskrywing. Teken die beperkings saam met die uitkoms aan eerder as om hulle stilweg te laat val wanneer jy rapporteer. Skryf die pad neer terwyl jy besig is: toestel, rol, en of sy toestand hoegenaamd gelees kan word.
Wat ’n vergelyking van paaie vir jou koop, is ’n beperkte vraag: die vloei oorleef op die een en sterf op die ander ná ’n soortgelyke stilte, so die veranderlike woon iewers in die dele wat verskil. Dit is ’n werklike resultaat selfs wanneer geen toestel genoem word nie, en dit sê vir die volgende ingenieur waar om ’n middag te spandeer en waar nie.
Plaaslike toestand is die moeite werd om te lees voordat jy oor vervoerders spekuleer. Op ’n Linux-poort lys conntrack -L die gevolgde vloei met hul oorblywende lewensduur, wat ’n raaiskoot oor ’n tydsverloop verander in ’n getal wat jy kan sien verstryk. Lees dit voor en ná die onaktiewe tydperk, nie net daarna nie.
Wat ’n aktiefhou kan hou en wat nie
’n Ondersteunde aktiefhou hou ’n kaartering oop, en om ’n kaartering oop te hou bewys niks oor die diens daarachter nie. Die tonnel kan gekarteer bly terwyl die toepassing wat dit dra opgehou antwoord het, en uit ’n statuslig lyk daardie twee situasies dieselfde. Behandel ’n aktiefhou as versekering teen onaktiewe verval, nie as ’n gesondheidstoets nie.
Stel die interval teen die kortste tydsverloop wat jy werklik gemeet het, eerder as ’n getal wat uit ’n forum gekopieer is. ’n Aktiefhou wat onder elke moontlike tydsverloop ingestel is, is verkeer wat niemand nodig gehad het nie, en dit verwyder ook die simptoom wat jou sou vertel watter grens eerste verval. Kies die interval uit die gemete getal en laat alles anders alleen.
Een verandering, meet dan weer
Weerstaan die drang om elke tydsverloop te verhoog en elke poort tydens ’n lewendige toets te spoel. Dit wis die bewyse waarvoor jy gekom het en onderbreek vloei wat aan ander mense behoort, wat ’n slegte ruil is vir ’n hipotese wat jy nie getoets het nie. Verander een ondersteunde instelling op een toestel, herhaal dan die onaktiewe tydperk en die toepassing se herstel.
Teken aan watter grens-waarneming beweeg het, en teken dit aan selfs wanneer niks verbeter het nie. ’n Instelling wat niks reggemaak het nie, is inligting, en dit is goedkoper om dit een keer raak te sien as om dit oor die hele landgoed te rol.
Om ’n bevinding te skryf wat jy kan verdedig
Wanneer ’n opstroom-omsetter nie ondersoek kan word nie, sê net wat die bewyse ondersteun: die uitruiling sterf iewers langs hierdie stuk van die pad ná soveel stilte, en die verantwoordelike hop bly ontoegeskryf. ’n Begrensde stelling oorleef hersiening en wys die volgende persoon na die regte segment. Om ’n verborge roeteerder as die oorsaak te noem, doen nie een van die twee nie. Gee die begrensde bevinding aan wie ook al die onwaarneembare segment besit, met die interval aangeheg.
RFC 4787 beskryf waarom tydsverlope vir UDP-kaartering moeilik is om uit een eindpunt af te lei, en daardie moeilikheid is die rede waarom die begrensde bevinding die eerlike een is. Tydsverlope is werklik, en so ook die onsekerheid daaromheen.