Mukhang maayos ba ang VPN ng router pagkatapos ng pagkawala ng kuryente? Subukan ang apat na layer na ito

Ang router na umiilaw pagkatapos ng pagkawala ay naibalik ang configuration nito, hindi ang koneksyon nito. Pagkatapos ng pagkawala ng kuryente, maaaring ibalik ng router ang naka-save na profile ng VPN bago maging handa ang mga dependency na kailangan ng profile na iyon: maaaring nagsasanay pa ang modem sa itaas, maaaring mali ang orasan, at maaaring hindi pa natapos ang pagpapatunay. Inilalarawan ng ilaw sa dashboard at ng naka-save na configuration ang layunin, hindi ang gumaganang tunnel. Suriin ang apat na layer sa ibaba sa pagkakasunod-sunod sa halip na palitan ang profile, dahil iyon ang ginagawa ng mga tao sa pangalawa at pinagsisisihan sa una.

Ipinapalagay ng lahat dito na nasa lugar ka o may paraan ka ng pagpasok na hindi umaasa sa tunnel na sinusubukan mo. Kung wala, ayusin iyon bago ang susunod na pagkawala.

Unang layer: bumalik ba talaga ang WAN

Magsimula sa modem, hindi sa dashboard ng router. Ang router na natapos ang boot bago nagsanay ang modem nito ay nagpapakita ng malusog na interface na walang anuman sa likod, at ang tunnel ay walang kapareha na maabot. Kumpirmahin na talagang nagpapasa ang modem, pagkatapos kumpirmahin na nakuha ng router ang mga setting ng WAN na inaasahan mo. Suriin din kung nagbago ang address ng WAN: ang dynamic na address na bumabalik nang iba ay maaaring magpawalang-bisa sa isang tuntuning nakabatay sa address o isang malayong listahan ng pinapayagan, at mula sa loob ng network ay mukhang sira ng VPN iyon.

Ang ilang access network ay nangangailangan din ng bagong hakbang sa pagtanggap pagkatapos ng pagkawala. Basahin ang log ng client para sa unang yugto ng pagkabigo sa halip na manghula: pinangalanan ng unang error ang layer, at ang lahat pagkatapos nito ay bunga. Itala ang address at ang resulta ng pagtanggap sa ticket, dahil pareho nilang tinutukoy kung gagana ang parehong profile bukas. Ang nabagong address ay pag-aayos na limang minuto at misteryong dalawang oras.

Ikalawang layer: suriin ang orasan bago ang sertipiko

Ang maling orasan ay nakakasagabal sa bisa ng sertipiko at sa lahat ng nakabatay sa oras, at ang naka-embed na aparato na nagbo-boot nang walang gumaganang pinagmumulan ng oras ay maaaring manatili sa lumang petsa nang ilang sandali. Pagkatapos ay nabibigo ang pagpapatunay ng sertipiko dahil sa dahilang walang kaugnayan sa kredensyal. Ang error sa bisa na ang mga petsa ay taon ang layo ay tumuturo sa orasan; ang parehong error na may kasalukuyang mga petsa ay tumuturo sa sertipiko.

date -u
chronyc tracking

Gamitin ang sinusuportahang proseso ng pagbawi ng oras at kumpirmahin ang orasan ng router bago hawakan ang profile. Ang pag-off ng pagpapatunay upang malampasan ang error ay ginagawang permanenteng kahinaan ang pansamantalang problema sa pagkasunod-sunod, at ito ang pinakakaraniwang masamang pag-aayos sa sitwasyong ito. Kung walang orasang de-baterya ang aparato, mahalaga ang pagkakasunod-sunod ng boot: kailangan nito ng access sa network bago mai-sync ang oras, at oras bago mapatunayan ang isang tunnel. Iyon ang pagkakasunod-sunod na dapat ayusin kung naulit ang parehong pagkabigo pagkatapos ng bawat pagkawala.

Ikatlong layer: basahin ang sinasabi ng tunnel

Suriin ang estado ng tunnel mismo at ang resulta ng handshake o pagpapatunay nito, hindi kung nakaangat ang interface. Maaaring umiral ang interface nang walang naitatag na kapareha, at maaaring magpakita ang client na konektado habang nabibigo ang pag-renew ng key. Paghiwalayin ang mga timeout ng transport mula sa malinaw na pagtanggi: ang timeout ay nagmumungkahi na ang landas o kapareha ay hindi pa maabot, samantalang ang pagtanggi ay nangangahulugan na sumagot at tumanggi ang malayong dulo, kadalasan dahil sa kredensyal, sertipiko o pagkakakilanlan ng kapareha na hindi na tugma. Ang pagpapadala sa user sa pag-reset ng password dahil sa timeout ay nagsasayang ng hapon ng lahat.

Itago ang huling kilalang mabuting configuration upang maihambing ang mga field sa halip na muling buuin ang mga ito. Kung may nabagong field, ang pagbabagong iyon ang natuklasan. Ihambing ito field sa field sa naibalik na configuration sa halip na basahin lamang ang naibalik. Karamihan sa mga sorpresa pagkatapos ng pagkawala ay isang field na tahimik na bumalik sa default ng template.

Ikaapat na layer: subukan mula sa isang aparato sa ibaba

Buksan ang isang hindi mapanganib na pinapayagang mapagkukunan mula sa isang client sa likod ng router, pagkatapos kumpirmahin kung aling labasan o pribadong ruta ang talagang ginamit ng trapiko. Suriin ang DNS at bawat pamilya ng address na sinasabi mong saklaw, dahil ang sariling pagsusuri ng router ay maaaring magtagumpay habang mali pa rin ang patakaran ng client — ang pagsusuri ay kadalasang gumagamit ng ibang pinagmulan, ibang talahanayan o ibang landas ng resolver.

curl -s https://ifconfig.me
nslookup example.com

Kung bumagsak ang tunnel at hindi lamang mali ang configuration, magpasya kung dapat harangan ang mga apektadong client o maaaring gumamit ng aprubadong alternatibo. Ang pagpili na iyon ay kabilang sa plano ng failover bago ang pagkawala, hindi sa isang chat thread habang nangyayari ito. Isulat ang naobserbahang labasan at resolver sa ticket ng pagkawala. Ang dalawang linya ngayon ay nagtitipid sa susunod na tao ng isang oras ng paghula kung aling landas ang aktibo sa panahong iyon.

Ano ang dapat ayusin upang maging mas maikli ang susunod na pagkawala

Kung naulit ang pagkabigo, ang pag-aayos ay pagkakasunod-sunod, hindi configuration: itaas ang WAN, pagkatapos ang oras, pagkatapos ang tunnel, pagkatapos ang patakaran ng client. Ipinapahayag ito ng karamihan ng router bilang dependency o pagkaantala, at ang maikling sinadyang pagkaantala ay mas mabuti kaysa sa muling pagsulat ng profile.

Pagkatapos ay ulitin ang normal na pagsubok ng restart pagkatapos mong baguhin ito, kabilang ang pagsusuri sa panig ng client. Ang pagsubok ng restart na tumitingin lamang sa dashboard ng router ay sumusubok sa pinakamababang nagbibigay-kaalaman sa apat na layer.