Nakaangat ang tunnel, walang internet: saan humihinto ang pagpapasa

Kumokonekta ang client, dinadala ng tunnel ang ping sa gateway, at walang sumasagot sa kabila nito. Normal ang estadong iyon para sa gateway na talagang para lamang magbigay ng access sa mga protektadong network, at ito ay sira para sa isang inaanunsiyong labasan ng buong tunnel. Bago baguhin ang mga patakaran, tiyakin kung anong serbisyo ang ipinangako. Pagkatapos, sundan ang isang pampublikong kahilingan sa apat na lugar kung saan ito maaaring huminto. Isang kahilingan at isang pagkuha ng packet ang nagtatapos ng higit pa sa isang pahina ng haka-haka.

Tiyakin kung ang labasan sa internet ay talagang disenyo noon

Ang split-tunnel profile ay nagruruta lamang ng mga protektadong subnet sa VPN, kaya ang pampublikong pag-browse ay nagpapatuloy sa lokal na link at hindi kailanman hinahawakan ang gateway. Ang full-tunnel profile ay naglalagay ng default na ruta sa tunnel, na ginagawang responsable ang gateway sa buong daan. Parehong lehitimong disenyo ang dalawa, at ang pagkalito sa kanila ay gumagawa ng ulat ng sira kung saan wala. Basahin ang mga rutang inaanunsiyo ng client bago subukan ang anupaman, dahil sinasagot ng route table ang tanong na karaniwang mali ang pagkakalagay sa ticket.

Ang inilalagay ng client ay hindi laging iyon ang sinasadyang profile. Ang itinulak na ruta ay maaaring madaig ng lokal na rutang may mas mababang metric, at ang client na nagpapanatili ng LAN route habang nagdaragdag ng default na ruta ay kumikilos na parang split tunnel para sa subnet na iyon.

Sundan ang isang pampublikong kahilingan

Pumili ng isang destinasyon at sundan ito mula sa client palaabas. Sa client, tiyakin kung talagang pinipili ng packet ang tunnel at kung aling lokal na address ang ginagamit nito bilang pinagmulan. Pagkatapos, tiyakin ang gateway: dumarating ba ang packet, at lumalabas ba ito sa pampublikong interface. Ang bawat isa sa mga sagot na iyon ay nag-aalis ng isang buong kategorya ng sanhi.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Kung hindi kailanman nakita ng gateway ang packet, mali ang ruta ng client o ang pagpili ng tunnel. Kung dumarating ito at hindi lumalabas, ang problema ay sa gateway, at nalalapat ang natitirang tatlong pagsusuri.

Tiyakin ang pagpapasa, ruta at pagsasalin

Ang gabay sa pagpapasa na kasama ng strongSwan ay nalalapat sa gateway ng anumang uri ng tunnel: dapat payagan ang kernel na ilipat ang mga packet sa pagitan ng mga interface, at ang magagamit na ruta ay dapat tumuro sa internet. Pagkatapos, dapat pahintulutan ng patakaran ng firewall ang trapiko, at ang address ng pinagmulan ay dapat isang masasagot ng pampublikong panig. Ang pribadong address ng client na ipinasa nang walang pagbabago sa internet ay hindi kailanman tumatanggap ng sagot.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Ang pagsasalin ng pinagmulan ang karaniwang nawawalang piraso. Sa pamamagitan nito, muling isinusulat ng gateway ang pinagmulan ng client sa pampublikong address nito at sinusubaybayan ang daloy; kung wala ito, walang mapupuntahan ang sagot. Ang mga cloud platform ay nagdaragdag ng pangalawang hangganan, kung saan ang route table o security group ng instance ay maaaring magtapon ng trapikong pinapayagan ng firewall ng bisita. Madaling makaligtaan ang hangganang iyon dahil mukhang tama ang configuration ng bisitang sistema mula sa loob.

Ang reverse-path filtering sa isang asymmetric na setup ay maaari ring magtapon ng mga balidong packet. Basahin ang counter ng patakarang iyon sa halip na ipagpalagay na maayos ito, dahil tinatanggihan ng mahigpit na setting sa pampublikong interface ang trapikong dumarating sa ibang daan kaysa hinuhulaan ng route table.

Ang daan ng sagot at resolver ay dalawang magkaibang sagot

Panoorin din ang sagot, hindi lamang ang kahilingan. Kung ang kahilingan ay lumalabas na isinalin at ang sagot ay bumabalik sa isinaling daloy, gumagana ang pagpapasa kahit nabibigo pa rin ang application, at ang susunod na pagsisiyasat ay pag-aari ng application o ng DNS.

Ang site na nagbabalik ng HTTP error ay patunay na gumagana ang pagpapasa sa internet. Ang pangalang hindi nare-resolve habang gumagana ang access sa address ay problema ng resolver, hindi problema ng NAT.

Pagkatapos ng tumpak na pagwawasto, muling subukan ang client at anumang pribadong resource na sadyang nilimitahan. Ang pagbibigay ng access sa internet ay hindi dapat tahimik na magpalawak ng access sa bawat network na nakakabit sa gateway.