Suriin ang Linux VPN gamit ang ip link, layer sa layer

Sinasabi ng icon ng client na konektado ito, mayroon ang interface, at wala pa ring naaabot ang application. Karaniwan ang kombinasyong ito, dahil nananatili ang isang virtual interface kahit nawawala ang remote peer, ang mga address o ang mga route nito. Ang ip link ang tamang unang tool, at ito rin ang pinakamadaling sobrahan ng basa. Isang layer lang ang inilalarawan ng mga flag at counter, at hiwalay na nabibigo ang mga layer sa itaas nila. Ito rin ang tool na madalas banggitin ng mga tao kapag gustong patunayan na buhay ang tunnel, na siya mismong claim na hindi nito kayang suportahan nang mag-isa.

Basahin ang interface bago basahin ang icon

Magsimula sa ip -details link show dev tun0 gaya ng nakadokumento sa manwal ng ip-link, na pinapalitan ang karaniwang pangalan ng interface na aktwal na hawak ng iyong client. Kapaki-pakinabang na obserbasyon ang mga flag, type, MTU at pagkakakilanlan ng interface. Hindi kailangang umasta ang pananalita ng estado ng isang virtual interface tulad ng carrier indication ng pisikal na kable, kaya ituring ang UP bilang pahayag tungkol sa interface at hindi tungkol sa tunnel.

Ipinaliwanag ng pagkakaibang iyon ang pinakalito na kaso: isang interface na nananatili habang muling kumokonekta o hindi naaabot ang kabilang dulo.

Kayang panatilihin ng mga setting ng persistence ang link nang eksaktong para hindi na ito itayo muli ng reconnect, ibig sabihin, hindi kalusugan ang presensya.

Magdagdag ng counter at ng request na dapat gumamit sa mga ito

Gamitin ang sinusuportahang statistics view, ip -s link show dev tun0, at itala ang bilang ng packet at byte sa dalawang direksyon. Pagkatapos, gumawa ng isang walang peligrong request na dapat dumaan sa interface at ihambing ang kaugnay na direksyon. Ang request na dumaan sa direktang route ng ibang application ay hindi gagalaw sa mga counter, at iyon ang punto ng ehersisyo.

Kung gumagalaw ang transmit counter at hindi ang receive counter, umalis ang packet at walang bumalik. Ibang problema ito kaysa sa isang interface na talagang wala pang nadala. Kung gumagalaw ang dalawang counter at nabibigo pa rin ang application, nasa itaas ng interface ang sira, at iyon ay progreso at hindi dead end.

Dalawang beses kunin ang reading, isa bago at isa pagkatapos, sa halip na magtiwala sa isang snapshot.

Hiwalay na hakbang ang mga address at route

Maaaring umiral ang link nang walang prefix, walang resolver configuration o walang route na kailangan ng application. Suriin ang address gamit ang ip address show dev tun0, pagkatapos tingnan kung aling route ang pipiliin ng destinasyon gamit ang ip route get para sa aktwal na target. Tatlong magkaibang tanong ang sinasagot ng tatlong obserbasyong iyon, at ang huli lang ang tungkol sa forwarding.

Sa IPsec, maaaring mahalaga rin ang security policy at association state, at hindi lahat ng disenyo ng IPsec ay lumilitaw bilang simpleng tun interface. Ang maghanap ng tun device na hindi naman talaga iiral ay mabilis na paraan para magkonklusyon ng mali.

Itala ang eksaktong pangalan, ang namespace at ang oras kasama ng anumang output na itatabi mo, dahil ang magkatulad na pangalan sa ibang container o sa naibalik na session ay kumakatawan sa ganap na ibang konteksto.

Huwag burahin ang hindi mo pa natukoy

Hindi automatic na luma ang isang hindi pamilyar na interface. Tukuyin ang may-ari nito bago mag-alis ng kahit ano, at gamitin ang nakadokumentong teardown ng client o ang managed configuration kapag talagang sinasadya ang pag-alis. Ang pagbura ng live na tunnel para tingnan ang mangyayari ay isang test na sumasagot sa tanong na walang nagtanong.

Kung pag-aari ng container runtime o ng network namespace na hindi ikaw ang gumawa ang interface, isang command lang ang layo ng may-ari at sulit itong hanapin muna.

Naaangkop din ang pag-iingat na iyon sa ip link set down, na mukhang maibabalik at madalas ay hindi.

Ano ang dapat iwan sa iyo ng pagsusuri

Nagtatapos ang magandang pagsusuri sa apat na katotohanan: ang pangalan at namespace ng interface, ang mga flag at MTU nito, ang delta ng counter mula sa totoong request, at ang route at address na aktwal na kailangan ng application. Kapag naisulat na ang mga iyon, malinaw na ang susunod na hakbang at kabilang ito sa isang partikular na layer. Kung wala ang mga ito, haka-haka lang na may rollback plan ang bawat kasunod na pagbabago.

Ihambing ang apat na katotohanang iyon sa kaparehong apat mula sa gumaganang session. Kung tugma ang pangalan at namespace ng interface pero zero ang delta ng counter, hindi kailanman nakarating sa tunnel ang request. Kung malusog ang delta ng counter at iba ang tinutukoy ng route, maayos ang tunnel at hindi ang routing. Ang paghahambing na iyon ang nagiging desisyon sa isang tambak ng output.

Itabi ang output kasama ng ticket, dahil makabuluhan lang ang susunod na paghahambing kung nakikita mo kung ano ang nagbago.

Pagkatapos, isara ang loop sa pamamagitan ng muling pagsubok sa application, dahil hindi kailanman ang interface ang pinakamahalaga sa user.