Aling NAT hop ang nagtatanggal ng idle na VPN mapping, at paano ito malalaman
Ang idle na VPN flow ay maaaring mamatay sa alinmang hop na may estado. Ulitin ang isang pagsubok, ihambing ang nakita ng bawat hangganan, at iulat ang limitadong resulta sa halip na hinulaang salarin.
Pagkatapos ng tahimik na panahon muling kumokonekta ang tunnel, walang log na nagngangalan ng salarin, at ang halatang hakbang ay piliin ang device na may pinakakahanga-hangang dokumentasyon ng timeout. Iyon ay haka-haka na nakasuot ng diagnosis. Maaaring tumagal ang estado nang ilang sandali sa home router, sa translator ng carrier at sa cloud edge, at alinman sa mga ito ay maaaring magpahulog ng flow na tumatahimik. Ang magagawa mo sa halip ay imapa ang landas, markahan kung aling mga device ang talagang maaari mong obserbahan, at magsagawa ng isang idle na pagsubok na maaari mong ulitin.
Ang paulit-ulit na pagsubok ay ginagawang pagsukat ang anekdota. Ipinapalagay ng lahat ng nasa ibaba ang isang kliyente, isang server at isang protocol, at ipinapalagay na lumalaban ka sa pagbabago ng dalawang variable nang sabay. Layunin nitong gawing mas mura ang susunod na pangyayari kaysa dito.
Isagawa ang parehong idle na pagsubok tuwing
Isulat kung kailan huling maayos ang flow, gaano katagal itong idle pagkatapos, at kung isang sariwang packet ang nagbalik nito. Ang tatlong katotohanang iyon ang pagsukat; kung wala sila, may kuwento ka lang tungkol sa laptop na nahulog. Gamitin ang parehong kliyente, parehong server at parehong protocol sa bawat pag-uulit, at itala ang sandali nang ipadala ang unang packet pagkatapos ng katahimikan.
Pagkatapos ay ihambing kung ano talaga ang nakita ng bawat hangganang pag-aari mo. Ang pagkakaibang nagpapasya sa imbestigasyon ay kung wala talagang nakita ang server pagkatapos ng paghinto, o nakita nito ang kahilingan at sumagot sa landas na hindi na nagdadala ng mga sagot.
| 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 |
Paghahambing ng mga landas nang hindi binabago ang limang bagay
Ang pangalawang aprubadong access network ay lehitimong paghahambing, dahil naiiba ang NAT chain. Naiiba rin ito sa provider, kondisyon ng radyo at marahil sa pamilya ng address, kaya ang resulta ay hangganan, hindi pagbibintang. Itala ang mga limitasyon kasama ng resulta sa halip na tahimik na alisin ang mga ito kapag nag-uulat. Isulat din ang landas: device, papel, at kung mababasa man ang estado nito.
Ang binibili ng paghahambing ng mga landas ay isang limitadong tanong: nabubuhay ang flow sa isa at namamatay sa isa pa pagkatapos ng katulad na katahimikan, kaya ang variable ay nasa isang lugar sa mga bahaging naiiba. Totoo itong resulta kahit walang device na pinangalanan, at sinasabi nito sa susunod na inhinyero kung saan gugulin ang isang hapon at kung saan hindi.
Sulit basahin ang lokal na estado bago maghaka-haka tungkol sa mga carrier. Sa isang Linux gateway, inililista ng conntrack -L ang mga sinusubaybayang flow kasama ang natitirang buhay ng mga ito, na ginagawang numero mula sa haka-haka tungkol sa timer na makikita mong mag-expire. Basahin ito bago at pagkatapos ng idle na panahon, hindi lamang pagkatapos.
Ano ang tatagal ng keepalive at ano ang hindi
Ang sinusuportahang keepalive ay nagpapanatiling bukas ng mapping, at ang bukas na mapping ay walang pinapatunayan tungkol sa serbisyo sa likod nito. Maaaring manatiling naka-map ang tunnel habang ang application na dala nito ay tumigil nang sumagot, at mula sa status light ay magkapareho ang dalawang sitwasyong iyon. Ituring ang keepalive na seguro laban sa pag-expire dahil idle, hindi bilang health check.
Itakda ang agwat ayon sa pinakamaikling timeout na aktuwal mong sinukat, hindi ayon sa numerong kinopya mula sa forum. Ang keepalive na nakatono sa ilalim ng bawat posibleng timer ay trapikong walang kailangan, at tinatanggal din nito ang sintomas na magsasabi kung aling hangganan ang naunang nag-expire. Piliin ang agwat mula sa sinukat na numero at hayaang manatili ang lahat ng iba.
Isang pagbabago, pagkatapos ay sukatin muli
Labanan ang udyok na itaas ang bawat timeout at i-flush ang bawat gateway habang live na pagsubok. Binubura nito ang ebidensiyang hinanap mo at ginagambala ang mga flow ng iba, na masamang palitan para sa isang haka-hakang hindi mo pa nasusubukan. Baguhin ang isang sinusuportahang setting sa isang device, pagkatapos ay ulitin ang idle na panahon at ang pagbangon ng application.
Itala kung aling obserbasyon sa hangganan ang gumalaw, at itala ito kahit walang bumuti. Ang setting na walang naayos ay impormasyon, at mas mura itong mapansin nang isang beses kaysa ipalaganap sa buong estate.
Pagsulat ng natuklasang maipagtatanggol mo
Kapag hindi masuri ang translator sa itaas, sabihin lamang ang sinusuportahan ng ebidensiya: namamatay ang palitan sa isang lugar sa bahaging ito ng landas pagkatapos ng ganoong katahimikan, at ang responsableng hop ay nananatiling hindi nabibintang. Ang limitadong pahayag ay nakakalampas sa pagsusuri at itinuturo ang susunod na tao sa tamang segment. Ang pagpangalan ng nakatagong router bilang sanhi ay hindi ginagawa ang alinman sa dalawa. Ipaubaya ang limitadong natuklasan sa may-ari ng hindi maobserbahang segment, kalakip ang agwat.
RFC 4787 ang naglalarawan kung bakit mahirap hinuha ang mga timer ng UDP mapping mula sa isang dulo, at ang kahirapang iyon ang dahilan kung bakit ang limitadong natuklasan ang tapat. Totoo ang mga timer, at totoo rin ang kawalan ng katiyakan sa paligid ng mga ito.