Kumokonekta ang mga kliyente ng VPN ngunit walang internet: tatlong kulang na bahagi

Nakakuha ng address ang kliyente, tumutugon ang server sa ping, at nag-time out pa rin ang bawat pahina. Karamihan ng tao ay nagsisimulang i-edit ang profile ng kliyente sa puntong ito, na kadalasan ay sayang na pagsisikap: kapag nakaangat na ang tunnel, kailangang kumilos ang server na parang router. Tatlong kondisyon ang dapat matugunan nang sabay bago lumabas ang isang packet at bumalik ang tugon, at pareho ang sintomas alinman sa nawawala.

Bakit ang gumaganang tunnel ay wala pa ring daan palabas

Kailangang ipasa ng kernel ang mga packet sa pagitan ng mga interface, na naka-off bilang default sa karamihan ng mga distribusyon ng Linux. Kailangang isalin ang trapiko sa isang address na matutugunan ng labas na mundo, maliban kung alam na ng bawat upstream router ang pabalik na ruta sa subnet ng tunnel. Kailangang payagan ng forward na landas ng firewall ang trapiko sa dalawang direksyon, kasama ang mga tugon.

Ang bawat isa sa mga ito ay maaaring ayusin nang hiwalay, at iyon ang patibong. Ang pagpapagana ng pagpapasa nang walang tuntunin sa pagsasalin ay nag-iiwan ng mga packet na lumalabas na may pribadong pinagmulan at walang pabalik na landas. Ang pagdaragdag ng pagsasalin nang walang tuntunin sa pagpapasa ay nag-iiwan sa kernel na ibinabagsak ang packet isang hakbang mamaya.

Kaya subukan ang tatlong antas sa halip na ang kliyente, at baguhin ang isa kada pagkakataon upang may kahulugan ang resulta.

Ang pagpapasa ay isang switch ng kernel na dapat mong gawing permanente

Tingnan ang kasalukuyang halaga bago ito baguhin, pagkatapos itakda ito at kumpirmahin na nagkabisa ang pagbabago.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Ang unang utos ay nag-uulat ng kasalukuyang halaga, ang pangalawa ay nagtatakda nito habang tumatakbo, at ang pangatlo ay nagpapatunay na gumana ang pagsulat. Nawawala ang halaga habang tumatakbo sa susunod na pag-restart, kaya ang isang gumaganang sesyon ay maaaring masira pagkatapos ng maintenance nang walang anumang pagbabago sa configuration.

Gawin itong permanente sa isang file sa ilalim ng /etc/sysctl.d/, pagkatapos ilapat ang file na iyon sa halip na mag-restart upang malaman. Sa FreeBSD ang katumbas ay net.inet.ip.forwarding, at para sa pagiging permanente ay gateway_enable=YES sa rc.conf. Ang isang device na nag-uulat na patay ang pagpapasa ay nagpapaliwanag ng isang buong uri ng mga ulat na «dumarating ang mga packet at walang bumabalik». Tingnan din ang setting pagkatapos ng bawat upgrade, dahil ang muling itinayong kernel o pinalitang image ng device ay maaaring i-reset ito nang hindi sinasabi sa kahit kanino.

Pumili ng masquerade o isang nakapirming address ng pagsasalin

Sa isang dynamic na panlabas na address, ang masquerading ay ang pinakasimpleng tamang anyo. Pangalanan ang subnet ng tunnel bilang pinagmulan at ang panlabas na interface bilang labasan.

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

Sa isang static na pampublikong address, ang pagsasalin ng pinagmulan sa eksaktong address na iyon ay mas mahuhulaan at mas madaling i-audit.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Ang pangalawang anyo ay may dalang patibong sa maintenance: ang isang hard-coded na address na magbabago mamaya ay nagpapanatili sa tunnel na gumagana habang tahimik na humihinto ang access sa internet. Gamitin ang masquerade o i-update ang tuntunin tuwing ililipat ka ng provider. Mahalaga rin ang interface, dahil ang router na nagbabahagi ng sarili nitong upstream tunnel ay kailangang magsalin palabas sa tunnel na iyon at hindi sa pisikal na WAN.

Ang talahanayan ng filter ang ikatlong gate

Ang pagpapasa at pagsasalin ay maaaring parehong tama habang namamatay pa rin ang packet sa talahanayan ng filter. Ang ufw ay madalas na salarin: ang patakaran nito sa pagpapasa ay dumarating bilang DROP, at ang natitirang setup ay maaaring mukhang ganap na tama habang pinapatay ng nag-iisang setting na iyon ang trapiko. Ang pagtataas nito ay isang sadyang desisyon sa seguridad at hindi isang kahon ng tsek.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Pinapayagan ng unang tuntunin ang bagong trapiko mula sa tunnel palabas, at ang pangalawa ay ang mga tugon lamang pabalik. Palitan ang dalawa sa subnet ng tunnel at sa nilalayong destinasyon, dahil ang pangkalahatang pagpayag sa interface ng tunnel ay ginagawang bukas na labasan ang VPN para sa sinumang makapagpapatunay ng pagkakakilanlan.

Ang naka-bridge na tunnel ay nangangailangan ng ibang sagot. Ang address ay pag-aari ng bridge, hindi ng pisikal na port, kaya ang pag-alipin sa interface ay nag-aalis ng address na dati nitong taglay at ang host ay mukhang hindi maabot hanggang ang bridge mismo ay makakuha ng isa, na maaaring ibigay ng dhclient br0. Ang kabiguang iyon ay mukhang problema sa VPN at problema ito sa ikalawang antas. Tingnan ang sariling address ng bridge bago hawakan ang firewall, dahil ang pagbabago sa filter ay hindi makakapag-ayos ng host na wala nang address na mapagpapadalhan.

Saan titingin kapag hindi kailanman naglo-load ang isang pahina

I-ping ang address ng tunnel ng server upang patunayan na may tunnel. Pagkatapos ay patakbuhin ang traceroute mula sa kliyente patungo sa isang pampublikong address at basahin kung saan ito tumitigil: sa server dumarating ang packet ngunit hindi ito ipinapasa o isinasalin; sa kabilang dako ng server ang problema ay upstream at wala sa iyong mga kamay.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Ang unang utos ay nagpapatunay na dinadala ng tunnel ang trapiko hanggang sa server mismo, at ang pangalawa ay nagpapakita kung gaano kalayo nakakarating ang isang packet palabas. Ang bakas na nagtatapos sa address ng tunnel ay tumuturo sa pagpapasa o pagsasalin sa server, habang ang bakas na tumitigil isang hop mamaya ay tumuturo sa provider o sa pabalik na ruta ng upstream router.

Sa server, bantayan ang panlabas na interface habang naglo-load ang isang kliyente ng pahina. Ang trapikong lumalabas na may pribadong source address ay nangangahulugang kulang ang pagsasalin, at ang ganap na kawalan ng tugon ay nangangahulugang itinatapon ito ng forward na landas o ng upstream na pabalik na ruta.

Kung kailangan ding maabot ng mga malayong kliyente ang mga host sa LAN ng server, tandaan na kailangan ng LAN ng pabalik na ruta sa subnet ng tunnel. Iyon ay routing at hindi pagsasalin, at iyon ang hakbang na pinakamadalas malimutan kapag gumana na sa wakas ang daan patungo sa internet.