Ruta ng VPN o tuntunin ng firewall: alin ang nagtatapon ng packet?

Dalawang malayang desisyon ang nangyayari sa parehong packet, at alinman sa mga ito ay maaaring tapusin ang kahilingan nang tahimik. Pinipili ng paghahanap ng ruta ang isang interface at susunod na hop, pagkatapos ay nagpapasya ang filter ng packet kung pinapayagan ang kombinasyong iyon. Ang timeout ay nagsasabi sa iyo na isa sa dalawa ang tumanggi, hindi kung alin. Sundin ang mga yugto nang sunod-sunod at karaniwang hindi na hula ang pag-aayos.

Dalawang desisyon, isang packet, dalawang may-ari

Ang paghahanap ng ruta ay sumasangguni muna sa mga tuntunin ng patakaran, pagkatapos sa talahanayang itinuturo nila, at pinipili ang pinakatiyak na prefix na tumutugma sa destinasyon. Ang client na nag-install ng ruta ng tunnel ang may-ari ng desisyong iyon, at walang anuman sa tuntunin ng firewall ang makapapalit dito. Kapag ang paghahanap ay tumuturo sa hindi inaasahang lugar, bawat susunod na yugto ay gumagawa sa maling packet.

Hiwalay ang pag-filter. Sa isang host na Linux, hinahati ng mga hook ng netfilter ang trapiko ayon sa kanino ang packet: umaalis ang output sa makina, nagtatapos ang input dito, dumadaan ang forward dito. Ang gateway na tumatanggap ng mga client ng VPN at nagruruta sa kanila patungo sa LAN ay nangangailangan ng daan ng forward, at iyon mismo ang chain na iniiwang walang laman ng karamihan sa default na configuration.

Ang pagpili ng source ay kabilang sa parehong desisyon, at doon nagtatago ang karamihan ng hindi pagkakatugma. Pinipili ng kernel ang address ng source mula sa palabas na interface maliban kung may tinukoy ang ruta, kaya ang tuntunin ng filter na isinulat para sa subnet ng LAN ay hindi kailanman tumutugma sa packet na lumalabas gamit ang address ng tunnel.

Basahin kung ano talaga ang pinili ng paghahanap

I-print ang desisyon sa halip na hulaan ito. Nilulutas ng utos sa ibaba ang rutang gagamitin ng kernel para sa destinasyong iyon, kasama ang interface at ang source na pipiliin nito:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Madalas na nag-i-install ang mga client ng VPN ng mga tuntunin ng patakaran sa mga priority na mas mababa sa pangunahing talahanayan, kaya ang malinis na pangunahing talahanayan ay walang pinapatunayan nang mag-isa. Ihambing ang mga priority ng tuntunin sa mga talahanayang pinipili nila, at tingnan kung ang ruta ng tunnel ay nananatili pagkatapos ng muling pagkonekta sa halip na idagdag nang manu-mano nang isang beses.

Ang IPsec na nakabatay sa patakaran ay nagdadagdag ng ikatlong yugto ng pagtutugma na hindi saklaw ng routing, gaya ng inilalarawan ng mga tala ng forward ng strongSwan para sa tunnel at transport setup. Pinipili ng patakaran ng seguridad ang trapiko ayon sa prefix at protocol, habang ang ruta ay nagpapasya lamang kung saan pupunta ang isang packet na walang proteksyon. Ang subnet na niruruta ngunit walang tugmang selector ay nananatiling walang proteksyon o itinatapon, depende sa configuration, at wala sa mga resulta ang mukhang problema sa firewall. I-print ang patakaran at ihambing ang mga selector nito sa mga prefix na inaasahan mong dadalhin ng tunnel.

Nalalapat ang pag-filter sa isang hook, hindi sa isang ruta

Ang tuntuning nagpapahintulot sa listener ng VPN ay tuntunin tungkol sa trapikong nakadirekta sa gateway mismo. Wala itong sinasabi tungkol sa mga client na nakakarating sa mga host sa likod ng gateway na iyon, dahil dumadaan ang naipasang trapiko sa ibang chain. Ang pagbasa sa hanay ng tuntunin bilang isang patag na listahan ang karaniwang dahilan kung bakit ang tuntuning mukhang tama ay hindi kailanman pumaputok.

Mabilis na nilulutas ng mga counter ang tanong. Ang tuntunin na may zero na bilang ng packet ay hindi kailanman naabot, na tumuturo sa maling chain, maling interface, o naunang pagtatapon. Ang tuntunin na may tumataas na bilang sa ilalim ng patakaran ng pagtatapon ang hangganang hinahanap mo, at ang packet ay itinatapon sa halip na mali ang ruta.

Magpadala ng probe sa daang ginagamit ng client

Ang mga pagsubok na tumatakbo sa gateway mismo ay dumadaan sa output at input, gamit ang sariling address ng source ng gateway. Iba itong daan kaysa sa naipasang kahilingan ng client, kaya ang matagumpay na lokal na curl ay nagpapatunay ng mas kaunti kaysa sa nakikita. Subukan mula sa makinang nabibigo, o i-pin nang tahasan ang interface at ang source.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Ang paghuli sa magkabilang dulo ay naghihiwalay sa natitirang mga kaso. Ang SYN na umaalis sa client at hindi kailanman dumarating ay nangangahulugang routing, encryption, o listahan ng access sa upstream. Ang SYN na dumarating at walang sagot ay nangangahulugang ang serbisyo o ang filter ng host nito, at ang tunnel ay hindi kailanman naging problema.

Ang trapikong pabalik ay nararapat sa sariling pagtingin. Ang asymmetric na routing kasama ang reverse path filtering ay nagtatapon ng mga sagot na dumarating sa maling interface, na lumilitaw bilang one-way na koneksyon sa halip na naka-block na port. Tingnan ang halaga ng sysctl bago sisihin ang firewall sa sintomas na hindi nito ginawa.

Gumagana ang pag-log bilang pangalawang opinyon, hindi unang hakbang. Ang pansamantalang pahayag ng log sa chain ng forward ay nagpapangalan sa interface at mga address na tumama rito, at madaling alisin pagkatapos. Iwanan ito nang permanente at nakagawa ka ng problema sa dami ng log sa halip na sagot.

Ilagay ang bawat pagbabago kung saan ito nananatili pagkatapos ng muling pagkonekta

Ang rutang idinagdag gamit ang ip route add ay nabubuhay hanggang bumaba ang interface. I-save ito sa profile ng koneksyon sa halip: tumatanggap ang NetworkManager ng karagdagang ruta sa koneksyon, at pinapanatili ng netplan ang mga ito sa pagitan ng mga boot. Nalalapat ang parehong tuntunin sa eksepsyon ng firewall sa panig ng client, na nawawala pagkatapos ng susunod na pag-reload.

Ang mga tuntunin sa panig ng server ay kabilang sa configuration file na nilo-load ng serbisyo sa pagsisimula, hindi sa interactive na sesyon na nagtatapos kapag isinara mo ito. Isulat ang tuntunin, i-reload, at kumpirmahin na gumalaw ang counter, dahil ang pag-reload na tumanggi sa syntax ay tahimik na iniiwan ang lumang hanay ng tuntunin sa lugar nito.

Pagkatapos ay ulitin ang orihinal na kahilingan ng application mula simula hanggang dulo at itala kung aling layer ang nagbago. Ang pag-aayos ng ruta na nangangailangan din ng pagbabago sa filter ay mabibigo pa rin, at ang pangalawang pagkabigo ay mas madaling basahin kapag alam mong wala na ang una. Itala ang petsa at bersyon ng client sa tabi ng resulta, dahil ang mga default ng routing at filtering ay parehong gumagalaw sa pagitan ng mga release. Panatilihin ang talaan sa ticket upang ang susunod na tao ay magsimula kung saan ka tumigil sa halip na ulitin ang dalawang-yugtong paglalakbay.