Paano malalaman kung ang VPN tunnel sa Linux ay talagang gumagana

Ang cron ay nagre-restart ng ganap na malusog na VPN tuwing sampung minuto, at ang parehong trabaho ay nag-iiwan ng patay na tumatakbo nang isang linggo. Ang parehong pagkabigo ay nagmumula sa pagtrato sa «gumagana» bilang isang katotohanan lamang gayong hindi bababa sa apat ito. Ang isang aparato ay maaaring administratibong pinagana, tama ang ruta, ganap na naka-encrypt at wala pa ring dalang kapaki-pakinabang. Paghiwalayin muna ang mga obserbasyon, at ang pagsusuri ay halos magsusulat mismo.

Inilalarawan ng mga flag ng link ang aparato, hindi ang landas

Ang pagsusuri na kinokopya ng lahat ay naghahanap ng hardware address na puro sero. Ang trick na iyon ay naghihiwalay ng tunay na interface sa isang placeholder sa ilang driver at walang pinatutunayan sa iba, dahil ang aparatong tun ay walang MAC na maipapaulat sa simula pa lang. ip -brief link show tun0 sa halip ay nagbibigay ng mga flag: UP ay nangangahulugang pinagana ng administrator ang aparato, at LOWER_UP ay nangangahulugang itinuturing ng driver na magagamit ang link. Kapag binasa nang magkasama, sinasabi nilang umiiral ang aparato at hindi administratibong patay. Wala sa kanila ang nagsasabing may matutunguhan ang packet.

OpenVPN ay gumagawa ng sarili nitong tun aparato bago i-install ang mga ruta, kaya ang mga flag ay maaaring magmukhang perpekto habang wala pang naka-ruta. Tratuhin ang mga ito bilang paunang kondisyon, hindi kailanman bilang sagot.

Itanong kung saan pupunta ang packet

Ang paghahanap ng ruta ay sumasagot sa tanong na hindi kayang sagutin ng mga flag. ip route get 10.8.0.1 from 10.8.0.2 ay pinangalanan ang interface, ang source address at ang talahanayang gagamitin ng kernel, at iyon mismo ang dapat suriin ng split tunnel. Kung walang source address, iba ang itinatanong mo, at sa policy routing maaaring mag-iba ang sagot ayon sa source. Ito ang pinakamurang tapat na pagsubok, dahil kumukonsulta ito sa parehong mga patakaran na gagamitin ng iyong trapiko.

Para sa WireGuard, idagdag ang handshake. wg show ay nagpi-print ng tatak ng oras ng huling handshake sa bawat peer, at ang tatak na tumigil sa pag-usad ay nangangahulugang wala na ang peer, anuman ang sabihin ng mga flag ng interface. Ang naka-configure na interface na walang kamakailang handshake ay isa sa mga pinakakaraniwang maling positibo sa sariling gawang pagmamanman.

Ang talahanayan 220 ay nagsasalaysay ng kuwento ng IPsec

Ang strongSwan ay nag-i-install ng mga ruta para sa napagkasunduang selector sa talahanayan 220 kapag naka-enable ang pag-install ng ruta. ip route list table 220 kaya hinihiwalay nito ang napagkasunduan sa naka-ruta: ang walang laman na talahanayan sa tabi ng load na koneksyon ay nangangahulugang umangat ang IKE at CHILD SA habang walang trapikong itinutuon sa kanila. Suriin ang ip xfrm state sa tabi nito, dahil inililista nito ang mga naka-install na security association at ang kanilang mga endpoint.

Ang patakarang patibong ang kaso na dapat bantayan. Naghihintay ito ng kawili-wiling trapiko sa halip na i-ruta ito, kaya nananatiling walang laman ang talahanayan hanggang may mag-trigger ng tunnel.

Ang estado ng manager at estado ng daemon ay magkaibang listahan

Ang NetworkManager ay naglilista lamang ng mga koneksyong pag-aari nito. nmcli -t -f NAME,TYPE connection show --active ay walang ibinabalik para sa tunnel na direktang sinimulan ng wg-quick o ng isang daemon ng OpenVPN.

Mahalaga ang pagkakaibang iyon kapag kailangang magpasya ng script kung alin sa dalawang manager ang tatanungin. Piliin ang tunay na may-ari ng tunnel sa host na ito at huwag pansinin ang katahimikan ng isa. Kung pareho silang umiiral, magpasya kung alin ang may awtoridad at i-disable ang pangalawa, dahil ang dalawang manager na nagsusulat muli ng mga ruta sa isang interface ay gumagawa ng mga pagkabigong walang makapag-uulit. Ang nawawalang entry ay impormasyon tungkol sa manager, hindi tungkol sa tunnel.

Ikondisyon ang susunod na hakbang sa pagsubok na kailangan nito

Ang pag-poll ng UDP port ay walang pinatutunayang anuman tungkol sa kahandaan, dahil ang UDP ay walang handshake at nc -u ay nagtatagumpay sa sandaling lumabas ang packet. Subukan kung ano talaga ang kinokonsumo ng susunod na hakbang: isang TCP connection sa forwarded port, isang kahilingan sa host sa loob ng tunnel, isang pangalang nare-resolve lamang doon. Limitahan ang paghihintay sa isang timeout at bilang ng pagtatangka, at mabigo nang malakas kapag naubos ito.

Ang mga hook ay mas mahusay kaysa sa polling kapag inaalok ito ng client. --up at --down ang mga script ng OpenVPN ay tumatakbo pagkatapos magbago ng estado ang interface, na nag-aalis ng karera nang lubusan, ngunit tumatakbo ang mga ito gamit ang mga pribilehiyong pinanatili ng daemon. Kung bumaba ang OpenVPN sa isang account na walang pribilehiyo sa pamamagitan ng user at group, tumatakbo ang hook bilang account na iyon. Ang pag-restart ng serbisyo ng system ay nangangailangan noon ng sudo upang payagan ang eksaktong utos na iyon. Ipagkatiwala ang pagsubok muli sa manager ng serbisyo sa halip na sa isang cron loop: ang limitadong patakaran sa restart na may start limit ay naglalantad ng sirang tunnel, habang ang walang limitasyong loop ay nagtatago nito nang walang hanggan.