Inilagay mo ang VPN address sa whitelist at naka-block pa rin? Subaybayan

Bihirang ayusin ng paglalagay sa whitelist ng address na ipinapakita ng VPN app ang isang naka-block na port, at ipinapaliwanag ng packet kung bakit. Hindi binabalewala ng firewall ang iyong patakaran; sinusuri nito ang isang source address na walang ipinapakita sa screen ng kliyente. Hanggang sa iulat ng destinasyon ang halagang iyon, haka-haka lang ang bawat pag-edit ng patakaran.

Magsimula sa kahilingang dumarating sa serbisyo. Ang tunnel address, ang exit address at anumang pagsasalin sa pagitan nila ay nananatiling palagay hanggang kumpirmahin ng destinasyon ang isa sa mga ito.

Ang address sa app ay hindi ang dumarating

Nagdadala ang koneksyon ng VPN ng hindi bababa sa apat na address na sulit pangalanan nang hiwalay: ang endpoint ng server, ang panloob na tunnel address na itinalaga sa iyong kliyente, ang lokal na Wi-Fi o Ethernet address, at ang pampublikong address na nakikita ng isang website pagkatapos umalis ng trapiko sa provider. Maaaring ang pangalawa lang ang ipinapakita ng window ng kliyente. Pangalanan ang apat bago pangalanan ang isang patakaran. Sa split tunnel, ang mga kahilingan sa pampublikong destinasyon ay maaaring lumaktaw nang buo sa tunnel, kaya ang nabigong session ay hindi ang inaakala ng user na sinimulan niya.

Magpasya kung alin sa apat ang dapat pahintulutan ng patakaran, pagkatapos ay i-verify mula sa kabilang panig. Kung ang pangangailangan ay talagang address ng opisina, ang kondisyon ay ang ruta kasama ang kaayusan ng labasan ng site na iyon, at ang koneksyong may label na Office VPN ay hindi nagbibigay ng alinman sa dalawa nang mag-isa.

Subaybayan ang isang kahilingan hanggang sa hangganan ng pag-filter nito

Kumpirmahin ang destination address at port na ginagamit ng kliyente, pagkatapos ay suriin na sinusunod ng destinasyong ito ang rutang inaakala mo. Ang nai-publish na container port, reverse proxy o port forwarding ay maaaring ilipat ang desisyon sa isang host na hindi mo kailanman na-edit. Ang bawat isa sa mga paglundag na iyon ay maaaring may sariling patakaran. Ang pagtatatag muna ng ruta ay nagliligtas sa iyo mula sa pagwawasto ng patakarang walang packet na nakakarating.

Sa isang awtorisadong Linux host, basahin ang mga aktibong patakaran sa pagkakasunod-sunod bago baguhin ang mga ito. Ang mga na-forward at container service ay madalas tumalon sa kanilang sariling chain, kaya suriin ang target ng paglundag pati na ang huling hatol.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Banggitin ang tumutugmang numero ng patakaran sa ticket. Kung wala ito, hindi malalaman ng susunod na mambabasa kung aling pag-edit ang nagbago ng resulta. Ang numero ng patakarang walang timestamp ay malabo pa rin.

I-verify ang ruta gamit ang isang limitadong paghuli

Isang hindi nakakapinsalang kahilingan at isang makitid na paghuli ang nagtatakda ng tanong na paulit-ulit na bumabalik. I-filter sa destination port at host na iniimbestigahan, limitahan ang bilang ng packet, at itigil ang paghuli sa sandaling matapos ang kahilingan.

tcpdump -ni any 'tcp dst port 9443' -c 20

Ihambing ang tatlong halaga nang magkatabi: ang pinagmulan sa paghuli, ang pinagmulang binabanggit ng tumutugmang patakaran, at ang pagtanggi na naitala ng app. Maaaring magkaiba ang lahat, at ang una lang ang nagpapaliwanag ng pagbagsak na pinagpasyahan ng isang patakaran ng IP. Ang na-forward na HTTP header ay kabilang sa antas ng proxy, kaya ang log na sumipi sa header na iyon ay hindi naglalarawan ng pinagmulang sinuri ng firewall.

Basahin ang pagkakasunod-sunod ng chain, hindi lang ang patakaran

Itinatala ng sanggunian ng iptables ang maayos na pagdaan, kaya ang pahintulot na nasa ilalim ng tumutugmang huling pagtanggi ay hindi kailanman nagliligtas sa packet. Ang koneksyong tinanggap nang mas maaga ay maaaring kumilos nang iba sa bago, kaya ang lumang tagumpay ay walang sinasabi tungkol sa bagong patakaran. Hanapin ang pagtanggi o pagbagsak sa itaas ng iyong pahintulot bago ipagpalagay na mali ang pahintulot. Sinasabi rin ng mga counter sa bawat patakaran kung aling patakaran ang nakakita ng packet.

Ang pagbura ng patakaran para makita ang mangyayari ay pagbabago, hindi obserbasyon. Basahin ang mga counter, itala ang numero ng patakaran, at itago ang orihinal na patakaran sa talaan ng pagbabago. Kung hindi maiiwasan ang pagsubok, patakbuhin ito sa isang kopya ng chain.

Baguhin ang patakarang kinokontrol ng may-ari nito

I-update lamang ang nilalayong patakaran ng pinagmulan at serbisyo, sa pamamagitan ng sinumang may-ari nito. Ang ibinahaging isinaling labasan ay maaaring kumatawan sa maraming user nang sabay, kaya ang pagpayag sa address na iyon ay hindi nagpapatunay ng sinuman, at ang mga pahintulot ng app sa likod nito ay nananatili kung nasaan sila.

Kapag patuloy na gumagalaw ang address, ang matibay na sagot ay isang matatag na labasan o isang na-verify na channel, hindi isang mas mahabang listahan ng eksepsiyon. Itala ang naobserbahang pinagmulan, ang destination port at ang numero ng patakaran.