OpenVPN na buong tunnel: magdagdag ng labasan sa internet sa panig ng server

Nagpapatunay ng pagkakakilanlan ang isang kliyente, tumatanggap ng address mula sa pool at naaabot ang mga serbisyo sa host ng VPN, ngunit bawat pampublikong destinasyon ay nauubusan ng oras. Ganito ang hitsura ng isang tunnel na walang labasan, at ganoon pa rin ito hangga't hindi totoo ang apat na magkakahiwalay na bagay. Dapat tanggapin ng kliyente ang isang default na ruta, dapat mag-forward ang server, dapat payagan ng firewall ang pagdaan, at kailangan ng mga sagot ng daan pabalik sa pool. Nagbabahagi ang apat na kabiguan ng isang sintomas, kaya baguhin ang isang bagay kada pagtatangka at itala ang resulta.

Itulak ang default na ruta at tiyakin kung ano ang inilagay ng kliyente

Maikli ang linya sa panig ng server, at apektado lamang nito ang mga kliyenteng tumatanggap ng itinulak na mga opsyon. Ang anyong def1 ay naglalagay ng dalawang kalahating default na ruta sa halip na burahin ang umiiral na default, na nagpapanatiling buhay ang kasalukuyang koneksyon habang hinuhuli pa rin ang bawat destinasyon.

push "redirect-gateway def1"

Pagkatapos muling kumonekta, basahin ang talahanayan ng routing ng kliyente sa halip na magtiwala sa profile. Sa Linux lumilitaw ang dalawang entry na /1 sa tabi ng orihinal na default, at ipinapakita ng Windows ang parehong pares bilang 0.0.0.0/1 at 128.0.0.0/1. Ang kliyenteng bale-wala ang itinulak na mga opsyon, o ang naka-configure na tanggihan ang mga ito, ay pinapanatili ang lumang default nito at hindi kailanman nagpapadala ng trapikong pang-internet sa tunnel. Ayusin ang tanong na iyon bago baguhin ang anumang bagay sa server, dahil walang tuntunin sa panig ng server ang makakabayad nito.

Ang pag-forward ay setting ng server, hindi setting ng VPN

Basahin ang flag ng pag-forward bago hawakan ang routing. Ang zero doon ay nangangahulugang tinatanggap ng kernel ang packet ng kliyente at tumatanggi itong ipasa, na mukhang eksaktong pagharang ng firewall mula sa kabilang dulo. Itakda ang halaga sa pamamagitan ng direktoryo ng configuration ng system upang mabuhay ito pagkatapos ng reboot.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Susunod, tiyakin na ang host mismo ay may gumaganang ruta patungo sa labasan ng internet. Ang kahilingan mula sa shell ng server ay nagpapatunay na magagamit ang paitaas na landas at wala itong sinasabi tungkol sa pag-forward ng packet ng isang kliyente, kaya tratuhin ang mga ito bilang dalawang magkahiwalay na pagsubok. Kung hindi maabot ng server ang destinasyon, walang dami ng configuration ng pag-forward ang makakatulong.

Payagan lamang ang pagdaang nilalayon mo, at wala nang iba pa

Ang mga na-forward na packet ay tumatawid sa landas na forward; ang trapikong nakadirekta sa host ng VPN mismo ay tumatawid sa input. Magkaibang desisyon ang mga ito, at ang pagbubukas ng landas na input ay hindi nagpapahintulot ng pagdaan sa makina. Ang pagpapalit-palit ng mga ito ang pinakakaraniwang dahilan kung bakit parang pinapayagan ng firewall ang lahat habang nauubusan pa rin ng oras ang mga kliyente.

Ang pinakamababang patakaran ay tumatanggap ng mga bagong koneksyon mula sa pool patungo sa interface ng labasan at tumatanggap ng mga sagot na kabilang sa mga itinatag na daloy. Ilagay ito sa may-ari ng set ng mga tuntunin na ginagamit ng iyong distribusyon, sa halip na magdagdag ng dobleng tuntunin sa bawat boot; nag-iipon ang mga dobleng tuntunin at nawawalan ng kahulugan ang mga counter.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ang pagpalit ng bawat chain sa tanggapin ay nagpapapasa sa pagsubok at nag-aalis ng dahilan kung bakit may firewall. Panatilihin ang saklaw sa pool at sa interface ng labasan, at hayaan lang ang walang kaugnayang pag-forward.

Bigyan ang mga sagot ng lugar na pupuntahan

Pribado ang mga address ng pool, kaya hindi direktang makapaghatid ng sagot ang isang pampublikong server sa mga ito. Maaaring isalin ng host ng VPN ang address ng pinagmulan sa paglabas, o may hawak na rutang pabalik sa pool ang isang aparato sa itaas.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Magdagdag ng eksaktong isang patong ng pagsasalin. Ang ikalawang NAT sa itaas ay nagtatago sa una at ginagawang halos walang silbi ang dalawang log kapag may nasira mamaya. Kung ang router sa itaas ay nagro-ruta na pabalik sa pool, labis ang pagdaragdag ng pagsasalin sa host, at ang daan pabalik ay nakadepende na noon sa configuration ng router na iyon at hindi sa iyo.

Ang mga instance sa cloud ay nagdaragdag ng isa pang pintuan, dahil itinatapon ng ilang plataporma ang mga packet na ang address ng pinagmulan ay hindi sa instance maliban kung hihinaan ang pagsusuring iyon. Ang setting na iyon ay nasa labas ng bisita at madaling makalimutan kapag gumagana ang isang lokal na makinang pangsubok.

Patunayan ito mula sa kliyente, hindi mula sa shell ng server

Magsimula sa numerikong kahilingang IPv4, pagkatapos ay paghahanap ng pangalan, pagkatapos ay ang aplikasyon. Ang ping ay nagpapatunay ng pag-forward at pagsasalin;wala itong pinapatunay tungkol sa resolusyon, dahil nagkakabisa lamang ang mga opsyon ng DNS kapag inilagay ang mga ito ng integrasyon ng kliyente.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Itala ang mga pagbabago at ang hakbang ng pag-urong habang nagpapatuloy, upang maibalik ang patakaran ng labasan sa isang aksyon kapag nabigo ang isang pagsubok. Sinasaklaw lamang ng recipe na ito ang IPv4; mag-imbentaryo ng IPv6 nang hiwalay bago sabihing dinadala ng deployment ang lahat ng trapiko.