Ano ang ibinubunyag ng mga lokal na log ng system tungkol sa koneksyon sa VPN
Itinatala ng operating system ang mga pagsisimula ng serbisyo, pagbabago ng adapter at mga pagkabigo ng ruta na hindi kailanman isinusulat ng isang app. Magbasa ng isang makitid na window at iugnay ito.
Bawat desktop ay may sariling talaan ng kung ano ang ginawa ng VPN, at ang export ng app ang karaniwang pinaka-hindi kumpleto sa mga ito. Itinatala ng mga tagapamahala ng serbisyo kung kailan nagsimula ang isang unit, itinatala ng kernel kung kailan lumitaw ang isang interface, at itinatala ng stack ng network kung kailan hindi naipatupad ang mga ruta. Wala sa mga pasilidad na ito ang nakakaalam kung ano ang intensyon ng client, at hindi alam ng client kung ano ang ginawa ng kernel sa kahilingan nito.
Ang pagbasa ng isang ganoong talaan nang hiwalay ay nag-aanyaya sa maling konklusyon. Magbasa ng dalawa, mula sa parehong minuto, at ang pagkakasunod-sunod ay makikita.
Tatlong pasilidad na may tatlong bokabularyo
Sa Linux, hinuhuli ng journal ng systemd ang mga mensahe ng lifecycle ng unit mula sa wg-quick@wg0 o sa plugin ng VPN ng NetworkManager, at ang ring buffer ng kernel ay nagdadala ng mga mensahe ng interface at routing. Sa Windows, hinahati ng event log ang kuwento sa mga provider ng system, WLAN at remote access, bawat isa ay may sariling identifier. Sa macOS, ang pinag-isang log ay nagdadala ng mga mensaheng nakapaloob sa subsystem na bahagya lamang naipapakita ng graphical na Console.
Hindi nagsasalin ang mga bokabularyo. Ang identifier ng event mula sa isang platform ay walang ibig sabihin sa iba, at ang screenshot ng dialog ng Windows ay walang pinapatunayan tungkol sa isang unit ng Linux.
Ang ibinabahagi ng tatlo ay isang timestamp, pinagmulan at kalubhaan, at ang triad na iyon ang nagpapangyari sa ugnayan sa pagitan ng log ng client at ng tala ng operating system. Nag-iiba rin ang pagiging available: ang isang container na walang journal, isang pinutol na imahe ng Windows, o isang antas ng log na binaba sa pagbuo ay maaaring magtago ng isang buong layer.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
Ano ang pinapatunayan ng konektadong linya at ano ang hindi
Ang event ng pagsisimula ng serbisyo ay nagtatala na ang lokal na unit ay hiniling na magsimula at hindi ito agad na lumabas. Hindi nito itinatala ang natapos na handshake, wastong susi ng kapares o gumaganang ruta. Ang pagtingin sa linyang iyon bilang patunay ng tunnel ang pinakakaraniwang maling pagbasa ng mga log na ito. Ang linya ay nagpapatunay ng intensyon at kalagayan ng proseso, at walang anuman tungkol sa maabot.
Ang kalagayan ng pagpapasa ay isang hiwalay na pagmamasid, at nagmumula ito sa talahanayan ng ruta at hindi sa anumang log.
Ang event ng adapter ay maaaring magpaliwanag ng tahimik na pagkabigo: umangat ang interface, naitalaga ang address, at hindi kailanman na-install ang mga ruta dahil tinanggihan ang mga ito ng isang tuntunin ng patakaran. Sa pagkakasunod-sunod na iyon, bawat nakikitang linya ay mukhang malusog habang walang niruruta, at ang tanging paraan upang makita iyon ay ihambing ang mga timestamp ng log sa talahanayan ng ruta sa parehong sandali. Itago ang sariling pagkakasunod-sunod ng mga event ng client sa tabi ng dalawa, dahil ang client ang tanging pinagmumulan na nakakaalam kung ano ang hiniling nito. Ang dalawang katotohanang kailangan mo nang magkasama ay halos hindi kailanman lumilitaw sa parehong linya.
Ang susunod na muling pagkonekta ay nagsusulat sa ibabaw ng kawili-wiling bahagi ng larawang ito, kaya kunin ang window sa unang pagkabigo sa halip na pagkatapos ng tatlong pagtatangka.
Iugnay ang isang makitid na window
Itala ang oras ng pagtatangka kasama ng timezone nito, pagkatapos ay hilahin ang ilang minuto sa paligid nito. Ang unang error sa window ay halos laging nauuna sa linyang pinagputol na sinipi ng mga ticket ng suporta.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
Sinasagot ng bawat command ang ibang bahagi ng tanong: ang una ay nagbibigay ng lifecycle, ang pangalawa ng kalagayan ng pagpapasa, ang pangatlo ng subsystem ng network ng macOS. Sa Windows, salain ang log ng system ayon sa pangalan ng provider sa halip na i-scroll ang buong channel, at i-export lamang ang mga tumutugmang event.
Panatilihing sapat na maliit ang sipi upang masundan ito ng mambabasa. Ang window na dalawampung minuto na may apat na kaugnay na event ay sumusuporta sa isang konklusyon; ang export ng buong araw na may libu-libong linya ay walang sinusuportahan.
Saan tumitigil ang mga talaang ito
Inilalarawan ng mga lokal na talaan ang device, hindi ang landas. Hindi nila maipapakita kung ano ang itinago ng provider, kung ang isang session ay itinugma sa isang account, o kung ano ang nakita ng isang destinasyon. Ang pahayag ng provider na hindi ito nagtatago ng mga log ay walang sinasabi tungkol sa operating system sa iyong laptop, at ang isang lokal na event ay walang pinapatunayan tungkol sa makasaysayang talaan ng provider.
Nagdadala rin sila ng mas maraming personal na data kaysa sa inaasahan: mga username, hostname, landas ng mount at identifier ng device ay lumilitaw sa mga ordinaryong mensahe ng system kahit na walang nilalaman ng pagba-browse. Alisin ang mga iyon bago maglakip ng anuman sa isang ticket, at itago ang orihinal sa ilalim ng normal na mga kontrol sa access.
Sa isang pinamamahalaang device, hilingin sa IT ang kaugnay na sipi sa halip na subukang burahin ang organizational logging. Ang layunin ng diagnostic ay isang makitid na tanong na sinasagot ng dalawang pinagmulan, hindi isang kumpletong kasaysayan ng makina.