Bakit hindi maabot ang subnet sa likod ng isang OpenVPN client?

Nagtatagumpay ang mga ping sa tunnel address ng server, mukhang tama ang sariling routing table ng client, at hindi pa rin maabot ang LAN sa likod ng client na iyon. Mukhang tama ang routing table ng client, may ruta ang server patungo sa tunnel, at naglalaho pa rin ang mga packet. Ito ang klasikong sintomas ng isang layer-3 tunnel na hindi alam na ang isa sa mga client nito ay gateway din.

Walang next hop bawat client ang isang tun interface. Isang interface lang na may maraming peer ang nakikita ng kernel, kaya ang desisyon kung aling client ang dapat tumanggap ng packet para sa malayuang LAN ay dapat gawin sa loob ng proseso ng OpenVPN. Ang desisyong iyon ay kinokonfigura gamit ang iroute, at kung wala ito ay wala nang mapupuntahan ang packet.

Nagruruta ang server ayon sa client, hindi ayon sa interface

Kapag kailangang magpadala ng packet ang server sa tunnel address ng isang client, malinaw ang sagot: pag-aari ng session ng client na iyon ang address. Kapag ang destinasyon ay isang buong subnet sa likod ng client na iyon, wala ang address sa sinumang kilala ng server, at ang rutang kernel patungo sa tunnel ay nagsasabi lamang ng "sa daang ito", nang hindi tinutukoy kung aling peer.

OpenVPN ay nilulutas ito gamit ang isang panloob na routing table na nag-uugnay ng isang destination prefix sa isang partikular na client. Ang table na iyon ay binubuo mula sa mga iroute entry, kaya hindi sapat ang isang ordinaryong ruta sa server host. Dinadala ng rutang kernel ang packet sa tunnel interface; ang panloob na pagmamapa ang nagpapasya kung aling session ang tatanggap nito. Iyon din ang dahilan kung bakit hindi kailanman lumilitaw ang pag-aayos sa output ng ruta ng kernel.

Kung wala ang pagmamapa, dumarating ang packet sa server, tumutugma sa rutang tunnel at itinatapon dahil walang client na nag-aangkin ng destinasyon. Walang nagre-record ng malinaw na error, kaya ang failure ay mukhang tahimik na black hole sa halip na routing loop.

Isulat ang iroute entry na nagpapangalan sa client

Nakatira ang iroute sa isang configuration file na partikular sa client, hindi sa pangunahing configuration ng server. Ituro ang server sa isang direktoryo gamit ang opsyong client-config-dir, pagkatapos ay gumawa ng file na ang pangalan ay ang common name ng certificate ng client at ilagay ang prefix sa loob nito.

Para sa isang sangay na ang LAN ay 10.20.0.0/24 at ang common name ng certificate ay branch-router, ang file sa path na iyon ay naglalaman ng linyang tulad ng iroute 10.20.0.0 255.255.255.0. Ang pangunahing configuration ay kailangan lamang ang opsyong direktoryo; ang prefix ay nakatira sa client.

Ang common name ang marupok na bahagi. Ang certificate na inisyu gamit ang ibang subject, o isang deployment na nagpapatunay ng mga user sa pamamagitan ng username habang ang file ay pinangalanan sa certificate, ay gumagawa ng file na hindi kailanman binabasa. Suriin ang pangalang aktuwal na iniuulat ng server para sa session, at isaalang-alang ang opsyong nagpapabigo sa isang client na hindi tumutugma sa halip na tahimik na kumonekta nang wala ang mga ruta nito. Ang pagpapalit ng pangalan ng file upang tumugma sa certificate ay isang limang minutong pagwawasto na pumipigil sa napakahabang gabi.

Ang isang client ay maaaring magmay-ari ng maraming prefix. Magdagdag ng isang linya ng iroute bawat network, at itago ang listahan sa tabi ng iba pang mga setting ng client na iyon upang manatiling audit-able ang pagmamapa.

Itayo ang return path sa dalawang direksyon

Ang pagdadala ng mga packet sa malayuang LAN ay kalahati ng trabaho. Kailangan ding ipadala ng client ang trapiko ng LAN na iyon sa tunnel, na karaniwang ginagawa sa pamamagitan ng pagtulak ng ruta sa client: isang linyang tulad ng push "route 10.8.0.0 255.255.255.0" ay nagsasabi sa bawat client kung paano maabot ang network sa panig ng server. Para sa sangay, ang katumbas na ruta ay tumuturo sa tunnel para sa lahat ng dapat nitong maabot sa panig ng server.

Ang direksyon ng pagbabalik ay nangangailangan ng may-ari sa malayong panig. Sa panig na iyon, may dapat na malaman ang daan pabalik: isang static na ruta sa LAN router na nagtuturo ng VPN pool sa server, o translation ng address sa server bago pumasok ang trapiko sa LAN. Pinapanatili ng static na ruta na nakikita ang orihinal na mga address sa mga log at patakaran ng access ngunit nangangailangan ng pakikipagtulungan ng may-ari ng LAN; ang translation ay self-contained ngunit itinatago kung sino ang aktuwal na kumonekta.

Dapat na naka-enable ang forwarding sa server host. Kung wala ito ay tinatanggap ng kernel ang packet mula sa tunnel at tumatangging ipasa ito sa interface ng LAN, na mula sa pananaw ng client ay mukhang kapareho ng kulang na iroute.

Suriin ang maabot gamit ang tamang probes

Subukan nang pa-layer sa halip na i-ping ang malayong dulo at manghula. Mula sa server, suriin na may panloob na pagmamapa para sa prefix at ang rutang kernel ay tumuturo sa tunnel. Mula sa client, kumpirmahin na ang itinulak na ruta ay naka-install at ang default na landas nito patungo sa address ng LAN ay ang tunnel.

Pagkatapos ay panoorin ang mga packet. Ang capture sa tunnel interface ay nagpapakita kung nagpapadala ang server patungo sa client, at ang capture sa LAN interface ay nagpapakita kung nagpapasa ito. Kung ang una ay nagpapakita ng mga packet at ang pangalawa ay wala, ang problema ay ang forwarding o isang filter; kung wala sa dalawa ang nagpapakita ng anuman, nabigo ang paghahanap nang mas maaga.

Dalawang server na pinag-uugnay ng isang tunnel ay inuulit ang parehong patakaran sa magkabilang panig: kailangan ng bawat isa ng iroute para sa pool ng isa, at kailangan ng bawat isa ang ruta at forwarding na nagpapaging-simetriko sa landas. Magkaibang usapin ang routing at patakaran dito. Ang routing ang nagpapasya kung saan makapupunta ang packet, samantalang ang isang patakarang FORWARD ang nagpapasya kung pinapayagan, kaya ang isang client na may dalawang linya ng iroute ay umaabot sa dalawang prefix maliban kung may filter na nagsasabi ng iba.