Pampublikong prefix sa OpenVPN: ayusin ang daan pabalik

Panoorin ang tunnel na bumangon at ang kliyente na mag-ping sa kabilang panig, at pagkatapos ay may pampublikong address na nabibilang sa likod ng VPN na sumasagot mula sa ibang lugar, o hindi sumasagot. Ang sintomas na ito ay karaniwang walang kinalaman sa cipher o sa mga certificate. Ang prefix na niruruta ng provider ay inihahatid bilang isang IP route, at ang pagdadala nito sa OpenVPN ay nangangahulugan ng muling paggawa ng rutang iyon sa dalawang antas at pagpapanatili ng source address sa daan pabalik. Hindi kailangang i-bridge ang WAN, at ang pagdaragdag ng address sa isang interface ay hindi gumagawa ng upstream route.

Dapat munang i-ruta ang prefix papunta sa iyo

Itanong sa provider kung paano inihahatid ang block. Ang prefix na niruruta sa pangunahing address ng iyong server ay iba sa mga address na inaasahang maabot ng provider nang direkta sa isang WAN segment. Tanging ang unang modelo ang gumagana sa disenyo rito.

Kung iruruta ng provider ang 198.51.100.64/28 sa iyong entry server, dumarating ang mga packet para sa range na iyon sa server at tumitigil doon maliban kung ipapasa mo sila. Kung i-bridge ng provider ang range sa iyong uplink sa halip, kailangang tumugon ng server ng ARP para dito, na ibang problema.

Subukan ang modelo ng paghahatid bago hawakan ang OpenVPN: mula sa labas, i-ping ang isang address sa block at tingnan kung aling interface ang tumatanggap nito. Kung walang dumarating, walang configuration ng tunnel ang makakatulong. Kung direktang sumasagot ang address sa WAN, nagbi-bridge ang provider sa halip na nagru-ruta, at hindi naaangkop ang disenyo sa ibaba.

Dalawang antas ng routing: kernel route at iroute

Kailangan ng OpenVPN ang prefix sa dalawang lugar. Kailangang malaman ng kernel na pag-aari ng tunnel device ang prefix, upang ang mga ipinapasang packet ay pumasok sa OpenVPN sa halip na sa default route. Kailangan ding malaman ng OpenVPN kung aling authenticated client ang may-ari ng prefix, at iyon ang iroute entry sa direktoryong partikular sa client.

Ganito ang hitsura ng route sa panig ng server, at dapat tumugma ang prefix at mask sa alokasyon:

ip route add 198.51.100.64/28 dev tun0

Ang configuration na partikular sa client ang nagtatalaga ng pagmamay-ari. Ilagay ito sa CCD file na pinangalanan ayon sa common name ng certificate ng client, at tiyakin na ang direktoryong iyon ang aktwal na binabasa ng server:

iroute 198.51.100.64 255.255.255.240

Ang dokumentasyon ng OpenVPN tungkol sa mga naka-rutang network ay naglalarawan ng dalawang antas at kung bakit magkahiwalay ang mga ito. Ang kernel route na walang iroute ay nagpapadala ng mga packet sa tunnel na walang may-ari, at itinatapon sila ng OpenVPN. Ang iroute na walang kernel route ay nag-iiwan ng mga packet sa default na daan ng server. Ang dalawang pagkakamali ay mukhang sirang tunnel mula sa panig ng client.

Kung saan nakatira ang address ng serbisyo

Ang delegadong prefix ay hindi katulad ng sariling mga address ng tunnel. Bilangin ang link mula sa pribadong espasyo kung gusto mo, at ilagay ang pampublikong address ng serbisyo kung saan talaga tumatakbo ang serbisyo.

Sa isang Linux client na tinatapos ang serbisyo nang lokal, sapat na ang isang host address:

ip address add 198.51.100.70/32 dev lo

Kung iruruta pa ang prefix patungo sa isang VM host o ibang LAN, i-configure sa halip ang downstream na daang iyon at ang pabalik na ruta nito. Hindi kailangang italaga ang bawat address sa block sa VPN client, at lumilikha ito ng mga salungatan mamaya.

Panatilihin ang pampublikong source sa daan pabalik

Ang sagot mula sa delegadong prefix ay dapat lumabas sa tunnel at maabot ang ruta ng provider. Kung ipapadala ito ng remote host sa sarili nitong ISP, ang source address ay mukhang palsipikado, at itinatapon ito ng provider o ng destinasyon. Ang solusyon ay isang tuntuning nakabatay sa source o isang dedikadong routing table, hindi isang mas malawak na NAT. Kung wala iyon, gumagana ang serbisyo mula sa peer ng tunnel at nabigo mula sa lahat ng ibang lugar.

Sa entry server, ang malawak na masquerade rule ang karaniwang salarin. Isinulat muli nito ang pampublikong source sa pangunahing address ng server, at hindi kailanman nakikita ng client ang tunay:

iptables -t nat -S POSTROUTING

Limitahan ang NAT sa mga pribadong VPN client na nangangailangan nito at iwanang hindi isinalin ang delegadong prefix. Pagkatapos ay tiyakin na ipinapasa ng server ang prefix, dahil itinatapon ito nang tahimik ng forwarding chain na may default na pagtanggi.

I-verify ang dalawang direksyon bago ito pagkatiwalaan

Ang verification ay apat na obserbasyon, hindi isa. Tiyakin na dumarating ang ruta ng provider, ipinapadala ng kernel ang prefix sa tunnel, iniuugnay ito ng OpenVPN sa tamang client, at bumabalik ang sagot na buo ang pampublikong source. Bawat obserbasyon ay may sariling command, kaya ang pagkabigo ay tumutukoy sa isang layer at hindi sa buong disenyo. Patakbuhin ang mga ito sa ganoong pagkakasunod-sunod pagkatapos ng bawat pagbabago sa configuration.

Itanong sa kernel kung aling daan ang tinatahak ng delegadong address, at panoorin ang tunnel habang tumatakbo ang isang kahilingan:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Maaaring ipawalang-bisa ng reverse-path filtering ang isang tamang ruta. Suriin ang epektibong setting sa tunnel at sa uplink, at tandaan na tinatanggihan ng strict mode ang trapik na ang source ay hindi tumutugma sa interface kung saan ito dumating:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Sa huli, subukan ang kaso ng pagkabigo. Itigil ang tunnel at tiyakin na hindi tumatagas ang pampublikong prefix sa ordinaryong uplink. Dapat ibalik ng pag-restore ng VPN ang serbisyo nang hindi pinalalawak kung aling mga port ang inilalantad ng host.