Patuloy pa ring nagtutulak ng lumang ruta ang OpenVPN? Tingnan kung ano ang na-load nito
Maaaring hindi kailanman nabasa ng server ang pagbabago mo, o hindi kailanman na-install ng client ang natanggap nito. Ihambing ang tumatakbong proseso, ang itinulak na listahan at ang rutang pabalik.
Nagdadagdag ka ng ruta, ini-restart ang serbisyo, kumokonekta muli, at ang talahanayan ng client ay eksaktong katulad ng dati. May dalawang magkaibang bagay na maaaring totoo: hindi na-load ng server ang pagbabago mo, o hindi na-install ng client ang natanggap nito. Wala silang pagkakatulad maliban sa sintomas, kaya ang unang hakbang ay alamin kung alin sa dalawa ang nasa iyo.
Ang paghahambing sa ibaba ay mula sa proseso papalabas, dahil ang proseso lamang ang makapagsasabi kung aling file ang may bisa.
Ang file na in-edit mo at ang file na binabasa ng proseso
Magsimula sa unit at sa command line na ginawa nito. Sa host na systemd, ipinapakita ng systemctl cat openvpn@server ang linyang ExecStart, at ang instance unit ay karaniwang kumukuha ng configuration path nito mula sa pangalan ng instance, kaya ang daemon na sinimulan bilang openvpn@office ay nagbabasa ng ibang file kaysa sa sinimulan bilang openvpn@server. Ihambing iyon sa argv ng tumatakbong proseso. Ang configuration management tool ay nagdadagdag ng isa pang paraan upang mawala ang pagbabago: maaari nitong isulat ang tamang file sa lokasyong hindi kailanman binanggit ng unit, at pagkatapos ang matagumpay na deployment ay mukhang walang ginawa.
Ang mga timestamp ay mabilis na nagpapasya: kung ang file ay mas bago kaysa sa oras ng pagsisimula ng proseso, hindi ito mababasa ng proseso. Ang firmware ng router ay nagdadagdag ng ikatlong kaso, dahil maraming modelo ang nagtatago ng settings sa flash at muling binubuo ang configuration sa boot, na ginagawang ganap na maling layer ang pag-edit ng file sa disk.
Ano ang itinutulak ng server at ano ang ini-install ng client
Ang itinulak na ruta ay kailangang dumaan sa dalawang filter. Sa server dapat itong nasa na-load na configuration, hindi sa block na naka-comment o sa file na espesipiko sa client na hindi tugma ang pangalan. Sa client, dapat nakabukas ang pull at walang pull-filter na nagtatapon ng pagpipiliang iyon. Kumonekta gamit ang verbosity 4 at basahin ang itinulak na mga pagpipilian na iniuulat ng client: kung ang ruta ay nasa listahang iyon, nagawa na ng server ang trabaho nito at ang client ang pumipili na huwag itong i-install.
Ang mga file na espesipiko sa client ay karaniwang pinagmumulan ng kalituhan. Ang file na pinangalanan ayon sa common name ng sertipiko ay nagtutulak ng mga pagpipilian sa client na iyon lamang, at ang pagkakaiba ng isang karakter ay tahimik na humihinto sa pagtutulak, walang error sa alinmang panig. Itinatala ng server ang common name na nakita nito sa pagkonekta, kaya ihambing ang halagang iyon sa pangalan ng file, hindi sa inaakala mong pangalan ng client.
Ang itinulak na prefix at ang rutang pabalik ay magkaibang problema
Ang client na sadyang binabalewala ang redirect-gateway upang mapanatili ang lokal nitong daan sa internet ay gumagawa ng ikalawang, walang kaugnayang puwang. Naabot ng mga probe ng server ang address ng tunnel ngunit hindi kailanman dumarating ang mga sagot, dahil ang sagot na patungo sa tunnel IP ng server ay dinadaan sa karaniwang default gateway ng client. Hindi kasalanan dito ang itinulak na subnet route; ang kulang ay isang rutang nagpapabalik sa trapiko para sa tunnel network ng server sa pamamagitan ng tunnel device.
Ang pagdaragdag ng rutang iyon sa client ay nag-aayos ng mga sagot sa mga probe na sinimulan ng server. Hindi ito kapalit ng itinulak na subnet route, at totoo rin ang kabaligtaran, dahil inilalarawan ng dalawa ang magkasalungat na direksyon ng paglalakbay.
Ihambing ang mga talahanayan sa magkabilang dulo
Pagkatapos ng anumang pagbabago, kumonekta muli at basahin ang talahanayan ng client para sa itinulak na prefix at para sa tunnel device. Pagkatapos ay subukan sa dalawang direksyon: mula sa client patungo sa host sa itinulak na subnet, at mula sa host na iyon pabalik sa client. Ang rutang umiiral ngunit walang trapikong dinadala ay nangangahulugan ng isa sa tatlo: hindi nagpapasa ang kabilang panig, itinatapon ng firewall ang daloy, o walang daan pabalik ang sagot.
Panatilihing magkasama ang tatlong identifier: ang configuration path, ang pangalan ng unit o instance, at ang pagkakakilanlan ng client na ginamit mo sa pagsubok.
Ang tatlong ito ay ginagawang limang minutong pagsusuri ang susunod na pangyayari sa halip na panibagong imbestigasyon, at sila ang kailangan ng katrabaho kapag ang tunnel ay naging problema ng iba.
Ang problema sa ruta na tumatagal kahit pagkatapos ng restart ay madalas na hindi problema sa routing; ang depekto ay nasa itaas ng talahanayang patuloy mong binabasa.