Saan nararapat ang ruta sa OpenVPN: sa kliyente o sa server?
Ang hubad na ruta sa configuration ng server ay nagbabago sa server, hindi sa kliyente. Piliin ang file ng kliyente, isang pangkalahatang push, o isang push para sa isang kliyente, at tingnan kung ano ang dumating.
Nagdadagdag ka ng route 10.60.0.0 255.255.255.0 sa configuration ng server, nag-restart, muling kumokonekta ng laptop, at hindi pa rin maabot ang subnet mula sa laptop na iyon. Tinanggap ang linya, malinis na nagsimula ang serbisyo, at walang mukhang mali sa log. Ang nangyari ay na-install ang ruta sa mismong makina na in-edit mo: naniniwala na ngayon ang gateway na maaabot nito ang prefix na iyon, habang walang sinabi sa kliyente. Ang paglalagay ang buong tanong, at may apat na lugar kung saan maaaring manirahan ang parehong linya.
Ang apat na lugar at kung sino ang tumatanggap sa bawat isa
Maaaring idagdag ang ruta ng sariling configuration ng kliyente, ialok sa bawat kliyente sa pamamagitan ng pangkalahatang push, ialok sa isang kliyente sa pamamagitan ng file na partikular sa kliyente, o isulat sa sariling konteksto ng pag-route ng server.
Ang apat na kasong iyon ay gumagamit ng halos magkaparehong syntax at nagbibigay ng ganap na magkaibang resulta. Ang unang tatlo ay nakakaapekto sa ipinapadala ng kliyente sa tunnel; ang ikaapat ay nakakaapekto sa kung paano naaabot ng server ang isang network, na kapaki-pakinabang kapag ang server mismo ay nangangailangan ng landas at nakakasama kapag napagkamalang distribusyon.
Magpasya kung alin sa apat ang gusto mo bago isulat ang linya, pagkatapos ay kumpirmahin ang tatanggap.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Bakit nakakagulat ang hubad na ruta ng server
Ang configuration ng server ang unang lugar na tinitingnan ng mga administrador, at ang direktiba ng ruta doon ay binabasa na parang pahayag tungkol sa network ng VPN. Hindi ito. OpenVPN ay itinuturing itong lokal na pag-install ng ruta sa makinang pinapatakbo ng daemon, na eksaktong parehong uri ng pagbabago na gagawin mo gamit ang ip route at pagkatapos ay kalilimutan.
Ang distribusyon ay nangangailangan na ang ruta ay i-push, at ang push ay nangangailangan na hilahin ito ng kliyente. Ang kliyenteng sinimulan na may mga hinila na opsyon na naka-disable ay ganap na binabalewala ang alok. Suriin ang dalawang dulo ng pakikipagkamay na iyon bago muling isulat ang file ng server, dahil hindi magrereklamo ang log ng server: mula sa panig nito, naipadala ang alok. Ang tinanggap na ruta ay nagiging epektibo lamang sa susunod na koneksyon, hindi kailanman sa session na kinaroroonan mo na.
Kapag nakita mo ang dalawa bilang magkahiwalay na operasyon, hindi na misteryoso ang kabiguan: naaabot ng server ang prefix, hindi ng kliyente, at ang dalawang pahayag ay totoo nang sabay.
Mga file bawat kliyente at ang pagkakakilanlang tinutugma nila
Ang file na partikular sa kliyente ay pinangalanan ayon sa pagkakakilanlang pinatunayan ng server, na bilang default ay ang karaniwang pangalan ng sertipiko. Ang palakaibigang pangalan ng koneksyon sa isang desktop client ay hindi ang halagang iyon, at ang hindi pagkakatugma ay gumagawa ng file na hindi kailanman binabasa.
Suriin ang direktoryo na aktuwal na ginagamit ng server, pagkatapos ay kumpirmahin na ang pangalan ng file ay eksaktong tumutugma sa pinatunayang pagkakakilanlan, kabilang ang malalaki at maliliit na titik.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Sa loob ng file na iyon ay kailangan pa ring i-push ang ruta, dahil ang konteksto bawat kliyente ay isang hanay ng mga opsyon na inilalapat sa session ng kliyenteng iyon, hindi isang lokal na talahanayan ng pag-route. Ang hubad na ruta doon ay may parehong problema gaya ng hubad na ruta sa pangkalahatang file.
Ang sariling file ng kliyente at ang tool na nagmamay-ari nito
Ang rutang inilagay sa configuration ng kliyente ay naka-install kapag kumonekta ang kliyenteng iyon at tinatanggal kapag nadiskonekta, na siyang tamang lifecycle para sa isang static na destinasyon.
Kung ang isang tagapamahala ng network ang nagmamay-ari ng profile, maaari nitong i-import ang mga opsyon na iyon nang isang beses at pagkatapos ay panatilihin ang sariling kopya. Ang pag-edit ng na-download na file pagkatapos ay walang binabago, na isang karaniwang dahilan ng "nandiyan ang ruta pero hindi nalalapat".
Suriin ang aktibong profile sa halip na ang file na na-download mo, at suriin ang mga na-import na setting na ipinapakita ng tagapamahala. Pagkatapos ay kumonekta at tanungin ang system kung aling landas ang ginagamit ng isang partikular na address, sa halip na ipagpalagay na nanalo ang tunnel dahil umiral ang ruta sa isang text file.
I-verify sa kliyente, pagkatapos ay suriin ang pabalik na landas
Tanungin ang sariling talahanayan ng pag-route ng kliyente tungkol sa destinasyon, hindi ang sa server. Ang paghahanap para sa isang host sa loob ng prefix ay sapat na upang ipakita ang interface at susunod na hop na gagamitin.
ip route get 10.60.0.10Kung ang paghahanap ay tumuturo sa tunnel, gumana ang distribusyon at ang natitirang problema ay nasa ibang lugar. Kung ito ay tumuturo sa default na gateway, hindi na-install ang ruta, na-filter ng isang opsyon sa panig ng kliyente, o kabilang sa isang profile na hindi ginagamit ng kliyente.
Ipagpalagay na gumana ang distribusyon at wala pa ring tumutugon: pagkatapos ay suriin ang pagpapasa sa gateway, ang pabalik na ruta ng kabilang panig, at anumang firewall sa pagitan nila. Pumipili ng landas ang ruta, hindi ito nagbibigay ng access.