OpenVPN iroute laban sa Ruta ng Kernel: Alin ang Nawawala?

Ang isang packet para sa 10.77.20.0/24 ay dumadaan sa dalawang magkaibang desisyon sa isang OpenVPN server: kailangang iabot ito ng operating system sa VPN interface, at kailangang malaman ng OpenVPN kung aling konektadong client ang may-ari ng prefix na iyon. Ang nawawalang kernel route ay nagtatapon ng packet bago pa ito makarating sa tunnel, at ang nawawalang peer route ay nagtatapon nito pagkatapos. Magkamukha ang dalawang pagkabigo kung titingnan mula sa malayong LAN, at isang utos sa bawat panig ang kailangan para matukoy kung alin ang nasa iyo.

Sa klasikong userspace na daloy ng data, dinadala ng kernel route ang packet papasok sa proseso ng tunnel at sinasabi naman ng iroute sa prosesong iyon kung aling peer ang dapat tumanggap nito. Hindi kapalit ng isa't isa ang dalawa, at ang configuration na may isa lamang sa kanila ay magmumukhang maayos hanggang sa unang ping.

Dalawang Desisyon, Hindi Isang Ruta

Isipin ang isang site-to-site na link kung saan nasa likod ng isang client lamang ang 10.77.20.0/24. Ang kernel route ng server, halimbawa ip route add 10.77.20.0/24 dev tun0, ay nagpapadala ng tugmang mga packet sa tunnel device. Pagkatapos, tinitingnan ng OpenVPN ang sarili nitong panloob na talaan, na binuo mula sa mga entry ng iroute sa direktoryo ng configuration ng client, para magpasya kung aling koneksyon ng peer ang tatanggap sa mga ito. Kung walang kernel route, hindi man lang umabot ang packet sa proseso, at kung walang peer route, umaabot ito sa proseso ngunit wala itong patutunguhan.

Madaling makalimutan ang paghahating iyon, dahil ang isang linya ng ruta sa profile ng client ay maaaring magmukhang gumagawa ng dalawang tungkulin. Hindi ganito: ang pag-push ng ruta ay nagsasabi sa mga client kung ano ang ipapadala sa tunnel, samantalang ang iroute ay nagsasabi sa server kung sino ang may-ari ng isang saklaw ng address sa likod ng client. Nasa magkaibang file sila, binabasa ng magkaibang panig, at nabigo sa magkasalungat na direksyon.

Saan Nabibilang ang iroute at Ano ang Sinasabi Nito

Nasa isang file bawat client ang entry, na pinangalanan ayon sa common_name ng client, sa ilalim ng client-config-dir, sa anyong iroute 10.77.20.0/24. Hindi lamang kosmetiko ang pagtutugma ng pangalan ng file: hinahanap ng OpenVPN ang authenticated identity at binabasa ang file na eksaktong may ganoong pangalan, kaya ang file na tinatawag na site-a ay may bisa lamang para sa client na ang common name ay site-a. Idagdag ang ccd-exclusive kung ang mga client na walang gayong file ay dapat tanggihan agad, na siyang tamang setting kapag bawat client ay isang site gateway. Panatilihing isang file bawat gateway at pangalanan ito ayon sa certificate subject na talagang inilalabas mo.

Subukan ang entry mula sa server bago sisihin ang malayong LAN. Inililista ng status file ang mga konektadong client kasama ang kanilang common name, at ang server na tumatakbo sa --verb 4 ay naglalagay sa log ng iroute na ini-install habang kumokonekta ang peer. Kung walang lumilitaw sa oras ng koneksyon, mali ang direktoryo ng file o mali ang identity na tinutukoy nito.

Ang Bitag: Naroon ang File, Mali ang Identity

Ang mukhang tamang iroute na nakakabit sa maling peer ay mas maraming oras ang nasasayang kaysa sa nawawalang file, dahil maayos ang lahat ng nakikita sa disk. Ang pagpapalit ng pangalan ng certificate, magkakaparehong common name, at ang username-as-common-name na nagbabago ng aktwal na identity ay lahat nagdudulot nito. Alamin kung aling identity ang na-authenticate ng server sa halip na kung alin ang inaasahan mo: ang status output ang awtoritatibo, habang ang pangalan ng file ay lookup key lamang.

Maaari ring mabuhay nang mas matagal ang isang ruta kaysa sa may-ari nito. Inilalarawan ng mga static route at entry ng iroute ang isang prefix, hindi ang garantiya ng pagiging available, kaya maaaring patuloy na ma-route ang trapiko patungo sa peer na kasalukuyang nadiskonekta.

Tapusin ang Daan Lampas sa Peer

Ang pagmamay-ari ng peer ay ang gitna ng daan, hindi ang dulo. Kailangang i-forward ng client ang mga packet mula sa tunnel papasok sa LAN nito, na nangangahulugang naka-enable ang IP forwarding sa host na iyon at may firewall rule na pumapayag sa transit. Ang mga host sa malayong LAN ay nangangailangan ng return path para sa tunnel address, maging ruta pabalik sa gateway o sadyang disenyo ng NAT sa panig ng client. Tiyakin ang forward setting sa client gamit ang sysctl net.ipv4.ip_forward sa halip na ipagpalagay ang default ng distribution.

Kung kailangang maabot ng iba pang VPN client ang subnet na iyon, lalaki pang muli ang kaayusan: kailangan ng server ng client-to-client, at kailangang i-route ng mga client na iyon ang prefix sa tunnel. Wala sa mga iyon ang ipinahihiwatig ng sariling routing table ng server.

Tiyakin ang isang destinasyon mula sa tunay na pinagmulan sa halip na mula sa server mismo. Ang ping mula sa isang walang kaugnayang host sa LAN patungo sa host sa likod ng client ay sumusubok sa return path, sa forwarding rule at sa pagmamay-ari ng peer sa isang galaw, samantalang ang matagumpay na handshake ay nagpapatunay lamang ng identity. Pagkatapos ay idiskonekta ang peer na may-ari at itala kung ano ang ginagawa ng ruta, dahil ang sagot na iyon ang iyong failure mode.