Nakakonekta sa OpenVPN pero walang naglo-load: isang paglalakbay mula sa kliyente pakanluran

Sinasabi ng window ng kliyente na Connected, nandiyan ang address ng tunnel, at umiikot pa rin ang browser. Normal ang kombinasyong iyon, dahil ang matagumpay na handshake ay nagpapatunay lamang na naayos ang tunnel; hindi nito sinasabi kung ipapasa ng server ang iyong mga packet, isusulat muli ang pinagmulan ng mga ito, o sasagutin ang iyong mga query sa DNS. Ang pagkakamaling ginagawa ng karamihan ay buksan muna ang configuration ng server. Sa halip, magtrabaho mula sa kliyente pakanluran, dahil ang bawat hakbang sa ibaba ay nagsasabi kung ang susunod ay sulit pang suriin.

Magsimula sa kliyente at lumabas

Magpatakbo ng tatlong pagsubok sa ayos na ito at isulat kung saan nabigo ang una. I-ping ang address ng tunnel ng server, na nagpapatunay na ang tunnel mismo ay nagdadala ng trapiko. I-ping ang isang pampublikong address sa pamamagitan ng numero, na nagpapatunay ng pagpapasa at pagsasalin nang hindi kinasasangkutan ng resolusyon ng pangalan. Pagkatapos ay subukang i-resolve ang isang hostname, na siyang tanging pagsubok na gumagamit ng DNS. Bawat resulta ay nag-aalis ng isang buong layer sa hinala.

Huwag tumalon sa ikatlong pagsubok dahil mas mabilis ang pakiramdam ng browser. Ang nabigong pag-load ng pahina ay sumasaklaw sa tatlong layer nang sabay, at doon nagsisimula ang mga tao at pagkatapos ay itinatayo muli ang tunnel na gumagana. Ang pahinang nabibigo ay hindi nagsasabi kung alin sa tatlo ang nasira.

Dalawang huli ang nagpapakita kung saan humihinto ang mga packet

Habang tumatakbo ang ping sa pampublikong address mula sa kliyente, kumuha ng isang huli sa interface ng tunnel at isa sa uplink na dapat makarating sa internet. Patakbuhin ang dalawa nang sabay upang magtugma ang mga timestamp.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Kung lumilitaw ang mga kahilingan sa tunnel at hindi kailanman sa uplink, itinapon ng server ang mga ito sa pagitan ng tunnel at ng kable, at ang dahilan ay pagpapasa o patakaran ng firewall para sa pagpapasa, hindi NAT. Kung lumilitaw ang mga ito sa dalawa, ginawa ng server ang bahagi nito at kulang ang sagot sa mas malayo, na tumutukoy sa pagsasalin, isang filter sa itaas, o isang paghihigpit mula sa provider.

Kunin ang pangalan ng uplink mula sa routing table, hindi sa tutorial. Bihirang tumugma ang mga cloud image at pinangalanang muli na adapter sa halimbawang interface sa isang gabay, at ang huling kinuha sa maling device ay mukhang eksaktong server na hindi nagpapasa:

ip -4 route get 9.9.9.9

Ang field na dev sa output na iyon ay ang pangalan na kakailanganin ng patakaran ng NAT mamaya, kaya itago ito.

Ang pagpapasa ay isang switch sa kernel at isang patakaran ng firewall

Kailangang pumayag ng kernel na magpasa sa simula pa lang. Basahin ang kasalukuyang halaga, pagkatapos ay gawing permanente ang setting sa halip na isulat lamang ito sa tumatakbong kernel:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Ang pagpapasa ay kalahati lamang. Sa host na gumagamit ng UFW, ang patakaran ng pagpapasa ay itinakda sa /etc/default/ufw at dapat na ACCEPT bago magkabisa ang reload. Ang default na drop sa landas ng pagpapasa ay nag-iiwan sa handshake na ganap na malusog habang tahimik na itinatapon ang bawat packet na sumusubok na lumabas sa tunnel, at iyon mismo ang sintomas na sinimulan mo.

Ang mga host na direktang namamahala ng nftables ay may parehong tanong sa ibang syntax. Tingnan ang mga counter sa chain ng pagpapasa habang tumatakbo ang pagsubok mula sa kliyente, dahil ang chain na kinukonsulta at ang chain na nagtatapon ay magkapareho ang hitsura sa isang configuration file.

Pangalanan ang tunay na exit interface sa patakaran ng NAT

Ang pagsasalin ng pinagmulan ay para sa interface na talagang lumalabas sa host, kasama ang pool na ibinabahagi ng server. Ang dalawang kalahati ng patakarang iyon ay dapat ilarawan ang katotohanan, at wala sa kanila ang opsyonal.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Ang klasikong kabiguan ay isang patakarang kinopya mula sa gabay na nagsasabing -o eth0 sa isang makina na ang adapter ay may ibang pangalan. Naka-install ang patakaran nang walang babala, hindi tumutugma sa anuman, at wala pa ring internet ang kliyente. Ang pool ang kabilang kalahati ng parehong pagkakamali: kung ang server ay nagbabahagi ng 10.44.0.0/24 at ang patakaran ay sumasaklaw ng 10.8.0.0/24, walang kailanman tutugma.

Tingnan ang mga counter sa halip na magtiwala sa teksto ng patakaran. Ang listahan ay nag-uulat ng mga packet bawat patakaran, at ang patakarang hindi kailanman tumutugma ay nananatiling zero gaano man ito kawasto ang hitsura. Bigyan ito ng isang minutong tunay na trapiko ng kliyente bago magbasa ng anuman sa numerong iyon:

iptables -t nat -L POSTROUTING -v -n

Ang zero na bilang ng packet pagkatapos ng tunay na pagsubok mula sa kliyente ay nangangahulugang mali ang pagtutugma, hindi na sira ang tunnel. Kapag tumugma na ito, i-save ang set ng patakaran upang makaligtas sa isang reboot; ang pag-aayos na nabubuhay lamang sa kasaysayan ng iyong shell ay nawawala sa unang restart.

Kung ang server ay isa ring cloud NAT instance, may boses din ang platform. Ang instance na nagsasalin ng mga address ay karaniwang nangangailangan ng source at destination check na naka-disable kung saan inaalok ng provider ang setting na iyon, at ang VPN port mismo ay dapat maabot mula sa labas.

Ang DNS ang pangalawang kabiguan sa likod ng una

Ang ping ayon sa address na gumagana habang nabibigo ang mga pangalan ay problema ng resolver, at may sarili itong dahilan. Ang kliyenteng nagpapanatili ng lokal na resolver nito ay nagpapadala ng mga query na iyon sa isang buong tunnel at naghihintay ng sagot na hindi kailanman dumarating, dahil ang lokal na resolver ay nasa maling panig na ng ruta.

Magtulak ng resolver mula sa server upang malaman ng kliyente kung saan magtatanong. Ang dalawang entry ay nagbibigay sa kliyente ng alternatibo kung ang una ay hindi maabot, at ang dalawa ay dapat na resolver na talagang pinapayagan ng tunnel.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Ang mga kliyente ng Windows ay maaari pa ring bumalik sa lokal na resolver, at iyon mismo ang layunin ng block-outside-dns na pigilan, kapalit ng pagkawala ng mga pangalan na tanging lokal na network lamang ang makakaresolba. Ang mga kliyente ng Linux na gumagamit ng systemd-resolved ay madalas na hindi pinapansin ang itinulak na resolver maliban kung i-install ito ng isang script, kaya suriin ang resolvectl status para sa device ng tunnel bago magpasya na ang pagtulak ay hindi pinansin.

Tapusin ang paglalakbay ayon sa nararanasan ng isang user. Mag-load ng tunay na pahina mula sa kliyente, kumpirmahin ang address na pinagmumulan ng paglabas, i-reboot ang server, kumonekta muli, at ulitin ang tatlong pagsubok. Ang ikalawang pag-ikot na iyon lamang ang nagpapatunay na ang mga na-save na patakaran, patakaran ng firewall, at itinulak na resolver ay nakaligtas nang magkasama.