Subaybayan ang VPN ng router nang hindi umaasa sa isang ilaw ng status

Sinasabi ng pahina ng status na konektado, berde ang ilaw, at hindi maabot ng opisina ang file server. Ang isa sa mga katotohanang iyon ay tungkol sa tunel at ang isa ay tungkol sa daang dumadaan dito. Ang subaybayan ang dalawa ay ang pagkakaiba sa pagitan ng alertong maaari mong aksyunan at ng alertong natututo mong balewalain.

Limang pagsusuri, nang sunud-sunod, mula sa peer pakanlabas.

Pagsusuri 1: estado ng peer o asosasyon

Ipinapakita ng bawat protocol ang sariling estado. Ipinapakita ng WireGuard ang pinakahuling handshake at mga counter ng paglilipat bawat peer sa pamamagitan ng wg show. Isinulat ng OpenVPN ang estado ng sesyon sa status file o management interface nito, at ipinapakita ng IPsec ang mga asosasyon ng seguridad sa pamamagitan ng mga tool tulad ng ipsec statusall. Ang patibong ay basahin ang timestamp bilang hatol: ang isang idle na peer ng WireGuard na walang ipapadala ay hindi mag-handshake kamakailan, at hindi iyon outage.

Ihambing ang timestamp sa inaasahang trapiko at mga setting ng keepalive bago tumawag ng kahit sino.

Pagsusuri 2: ang napiling ruta

Maaaring may interface ng tunel habang walang naka-route dito. Suriin ang talahanayan ng pagpapasa para sa destinasyong mahalaga sa iyo, hindi para sa sariling subnet ng tunel. Kung kulang ang prefix o tumuturo sa ibang lugar, walang kaugnayan ang estado ng peer.

Nahuhuli ng pagsusuring iyon ang pagkabigong hindi kailanman ipinapakita ng ilaw ng status.

Ang isang kapaki-pakinabang na ikalawang pagsusuri ay naghahambing din ng source address. Ibinabalik ng ip route get 10.20.5.10 ang susunod na hop, ang interface at ang gustong source, at sapat na ang maling source upang basagin ang trapikong pabalik sa dulong malayo. Itala ang inaasahang triple isang beses, pagkatapos ay mag-alarma kapag nagbago ang alinmang elemento. Nahuhuli ng nag-iisang linyang iyon ang mga pagbabago ng NAT, pagyayanig ng interface at mga pagkakamali sa routing na batay sa patakaran.

Pagsusuri 3: pinapayagang landas ng aplikasyon

Subukan ang isang bagay na kumakatawan sa tunay na pangangailangan. Ang ping na nagmumula sa router ay lumalabas mula sa sariling address at patakaran ng router, na maaaring iba sa ipinapasang trapikong LAN, at maraming host ang naglilimita sa ICMP. Kung ang pangangailangan ay pribadong serbisyo, subukan ang serbisyong iyon sa tunay nitong port.

Panatilihing katamtaman ang dami ng pagsubok. Ang loop ng pagsubaybay ay hindi dapat maging trapikong sinusukat nito.

Pagsusuri 4: ano ang nagbago at kailan

I-ugnay ang mga pagbabago ng WAN, pag-renew ng key, pagbawi ng ruta at mga pagkabigo ng aplikasyon sa isang timeline. Ihiwalay ang pagkabigo ng tunel mula sa fallback na rutang tahimik na nagbabalik ng ordinaryong access sa internet, dahil pareho silang nagbibigay ng magkaparehong ulat ng user at magkasalungat na diagnosis. Babaliktarin ng mga error sa timezone ang pagkakasunod-sunod, kaya gawing normal bago ihambing. Ang timeline ang nagpapalit ng apat na pagsusuri tungo sa isang dahilan.

Itabi ang mga log para sa mga transisyon, hindi para sa payload.

Pagsusuri 5: dapat pangalanan ng alarma ang hangganan

Ang alarmang nagsasabing VPN down ay nagpapadala ng tao sa maling lugar kalahati ng oras. Ang isa na nagsasabing ang handshake ng peer ay luma na nang labindalawang minuto, kulang ang ruta papuntang 10.20.0.0/16, o nabigo ang pagsubok sa port 445, ay tumutukoy sa isang partikular na pagsusuri.

Panatilihin ang mga operational counter sa halip na mag-browse ng mga payload. Sinasagot ng mga counter ang tanong ng pagsubaybay nang hindi nangongolekta ng nilalamang hindi mo kailangan.

At hayaang ang patakaran ng failover ang magpasya kung ano ang susunod. Dapat tukuyin ng pagsubaybay kung aling hangganan ang nabigo, hindi magbigay ng malawak na bypass tuwing nabigo ang isang pagsubok. Dinodokumento ng manual ng OpenVPN 2.6 ang status file at management interface na nagpapaging-scriptable sa unang pagsusuri.