Ang "File exists" ng OpenVPN sa isang ruta ay hindi problema sa file

Magsimula kung saan lumilitaw ang mensahe. Kumokonekta ang kliyente, umaangat ang tunnel, at pagkatapos ay iniuulat ng log na nabigo ang utos ng Linux na magdagdag ng ruta dahil sa File exists. Wala sa pangungusap na iyon ang tumutukoy sa sertipiko, susi o configuration file, kahit na ang mga salita ay nagpapahiwatig nito. Inilalarawan ng kernel ang talahanayan ng ruta nito, at ang prefix na hiniling mong i-install ay mayroon nang entry.

Sundin ang sariling pagkakasunod-sunod ng kliyente: ano ang hiningi nito, ano ang laman na ng talahanayan, sino ang naglagay ng entry doon, at pagkatapos lamang kung ano ang babaguhin. Bawat hakbang ay nag-aalis ng isang posibleng may-ari.

Ano ang talagang hinihingi ng kliyente

Bago ang pagkabigo, itinatala ng kliyente ang rutang balak nitong idagdag, karaniwang bilang destinasyon, netmask, gateway at kung minsan bilang metric o talahanayan. Ang linyang iyon ang kahilingan. Ang error na sumusunod ay ang sagot ng kernel, at ang dalawa ay dapat basahin nang magkatabi.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Ang di-zero na exit status ng route helper ay hindi gaanong nagbibigay-kaalaman kaysa sa teksto sa ilalim nito, dahil iba't ibang tugon ng kernel ang nagbubunga ng di-zero na status. Itago ang eksaktong mensahe; ang pagkakaiba ng umiiral na entry at hindi maabot na gateway ang tumutukoy kung alin sa mga sumusunod na seksyon ang naaangkop.

Basahin ang umiiral na ruta, hindi lamang ang address

Hindi sapat ang paghahanap sa talahanayan ng parehong tuldok na apatan. Ang ruta ay kinikilala ng family ng address, talahanayan, prefix ng destinasyon, metric, protocol at output device, at ang mga entry na nagbabahagi ng prefix ay maaaring legal na magkasama kapag nagkakaiba ang mga katangiang iyon. Ang bumabangga ay ang buong bagay, hindi ang teksto.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Ang huling utos ay sumasagot sa ibang tanong kaysa sa unang dalawa: hindi kung ano ang umiiral, kundi kung aling entry ang pipiliin ng kernel para sa destinasyong iyon ngayon. Kapaki-pakinabang ang dalawang pananaw, at madalas silang magkaiba nang sapat upang sulit na ihambing bago magbigay ng anumang konklusyon. Ang pagkakaiba nila ang kawili-wiling kaso, hindi error sa pag-round.

Itala ang prefix, talahanayan, metric at device sa tabi ng nabigong kahilingan. Kung ang umiiral na entry ay may parehong katangian at parehong susunod na hop, mayroon kang dobleng tagubilin at hindi problema sa routing.

Apat na may-ari na maaaring magkaroon ng isang prefix

Ang mga konektadong ruta ay nagmumula sa itinalagang address at ginagawa muli ng system sa tuwing umiiral ang address na iyon. Ang DHCP client o connection manager ay nag-i-install ng mga ruta bilang bahagi ng sarili nitong lifecycle. Maaaring may dalang parehong prefix ang ibang VPN client. At ang lokal na hook o script ay maaaring magdagdag ng isang hindi alam ng iba.

Bawat may-ari ay nangangailangan ng ibang pagwawasto. Ang konektadong ruta ay hindi sa iyo upang burahin; ang pag-alis nito ay maaaring makasira ng lokal na access bago pa maging magamit ang tunnel, at ibabalik ito ng kernel. Ang rutang pag-aari ng manager ay dapat baguhin sa pamamagitan ng manager na iyon, hindi sa manu-manong ip route del na kinakansela ng susunod na muling pagkonekta.

Ang pinanatiling interface ay nagpapadali ng parehong kalituhan. Kapag ang tunnel device ay nakaligtas sa isang muling pagkonekta, ang mga rutang naka-install ng custom na setup code ay maaaring naroroon pa sa ikalawang pagtakbo, kaya ang script na nagpapalagay ng malinis na estado ay nabigo sa ikalawang pagkakataon at gumagana sa una. Alinman sa sadyang linisin ang lumang entry o gawing idempotent ang setup code.

Ang block-local ay sumasagot sa ibang tanong

Kapag ang isang profile ay nagpapadala ng lahat ng trapiko sa tunnel, kailangang magpasya ng kliyente kung ano ang mangyayari sa lokal na network. Binabago ng flag na block-local ang desisyong iyon sa pamamagitan ng pag-route ng lokal na LAN sa tunnel habang pinapanatili ang dokumentadong pagbubukod para sa LAN gateway; ito ay pagpili ng patakaran sa trapiko na may nakikitang bunga sa maabot.

Hindi nito ipinapaliwanag kung bakit nagbalik ng error sa umiiral na entry ang pagdaragdag ng ruta, at ang pagtanggap dito bilang pangkalahatang pag-aayos ay nagtatago ng tunay na salungatan sa likod ng pagbabago ng patakaran. Kung ang iyong lokal na mapagkukunan ay hindi na maabot pagkatapos i-edit ang profile, ang flag na ito ay isa sa mga unang bagay na dapat suriin; kung nabigo ang pagdaragdag ng ruta, hindi ito ang sagot.

Ituring ito bilang desisyon kung aling mga destinasyon ang mananatiling lokal, na ginawa nang sadya at isinulat. Hindi ito switch na susubukan kapag mukhang nakakaalarma ang log.

Isara ang loop: alisin ang duplicate sa pinagmulan nito

Kapag alam mo kung aling may-ari ang may hawak ng entry, alisin ang dobleng tagubilin kung saan ito tinukoy. Maaaring ito ay linyang route sa profile, push mula sa server, o hook na hindi na kailangang tumakbo.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Pagkatapos ay kumonekta muli at kumpirmahin ang tatlong bagay: umaangat ang tunnel, nareresolba ang nilalayong destinasyon sa gustong landas, at nawawala ang pagkabigo nang walang bago na pumapalit. Ang malinis na log na may maling piniling landas ay hindi pag-aayos.

Kung ang prefix ay nangangahulugang lokal na LAN sa isang panig at malayong network sa kabilang panig, ang problema ay overlap ng address at hindi duplicate, at walang pagbura ang gagawa sa dalawang kahulugan na totoo nang sabay. Ang kasong iyon ay nangangailangan ng ibang plano para sa isa sa dalawang network. Magpasya kung aling panig ang muling bibigyan ng numero bago hawakan ang alinman.