Nakakonekta ang VPN pero hinaharang pa rin ng firewall: paano malalaman kung alin
Tumatakbo ang tunel at isang port ang nabibigo pa rin. Basahin ang landas, pagkatapos ang patakaran sa bawat layer, at baguhin ang pinakamakitid na tuntunin sa halip na patayin ang alinman sa dalawang kontrol.
Sabi ng kliyente konektado, tumatanggi pa rin ang resource, at ang karaniwang susunod na hakbang ay patayin ang isang bagay. Dalawang magkaibang trabaho ang ginagawa ng dalawang kontrol sa pangungusap na iyon: gumagawa ang VPN ng landas para sa sakop na trapiko, at nagpapasya ang firewall kada koneksyon kung papayagang dumaan ang trapiko. Ang gumaganang tunel na may patakarang tumatanggi ay mukhang sira ang tunel mula sa upuan ng gumagamit, kaya ang gawain ay alamin kung aling layer ang sumasagot. Narito ang pagkakasunod-sunod na sinusunod ko, kasama ang pagbasa na nagsasabi sa iyong huminto.
Ihiwalay ang landas sa patakaran
Simulan sa hugis ng kabiguan, dahil libre itong impormasyon. Ang pagbagsak ng packet ay gumagawa ng timeout: umuulit ang kliyente, walang bumabalik, at nakabitin ang utos hanggang sumuko. Ang pagtanggi ay gumagawa ng pagtanggi o reset: may sumagot at nagsabing hindi. Ang serbisyong hindi nakikinig ay tumatanggi sa host mismo, nang walang anumang firewall.
Ang tatlong resulta ay tumutukoy sa magkaibang layer. Ang timeout ay nangangahulugang may patakarang tahimik na nagtatapon sa isang lugar, o hindi umaalis ang landas sa makina. Ang tinanggihan ay nangangahulugang narating mo ang host at tinanggihan ng stack nito o ng lokal na firewall. Ang ganap na katahimikan, habang buhay ang interface ng tunel at walang landas sa destinasyon, ay nangangahulugang mali ang landas at walang tuntunin ng firewall ang makakapag-ayos nito.
Basahin ang landas sa isang pasada
Tiyakin na sakop ng tunel ang destinasyon bago tumingin sa kahit isang tuntunin. Ang split tunnel na nagdadala lamang ng subnet ng opisina ay hindi magruruta ng kahilingan sa ibang saklaw, at ang kabiguan ay mukhang harang ng firewall na hindi naman:
ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall
Binabanggit ng output ng ruta ang interface na lalabasan ng packet at ang source address na dadalhin nito. Kung ang interface na iyon ay ang iyong pisikal na network card at hindi ang tunel, ang problema ay sa routing o sa mga pinapayagang saklaw ng tunel, at kabilang ito sa configuration ng VPN at hindi sa firewall.
Ang isang bitag na partikular sa VPN ay karapat-dapat sa sariling pagsusuri. Sa WireGuard, ang AllowedIPs ng isang peer ay parehong ruta at cryptographic filter: ang packet na ang source address ay hindi tugma sa pinapayagang set ng peer ay itinatapon bago tingnan ang anumang tuntunin ng firewall. Kaya ang ganap na tamang firewall ng host ay maaaring nasa likod ng tahimik na pagtatapon na mukhang patakaran, at ang pagwawasto ay isang linya ng configuration ng susi, hindi isang tuntunin.
Basahin ang patakaran sa layer na sumasagot
Kapag tama ang landas, daanan ang patakaran mula sa host pakanlabas at pansinin ang nag-iisang layer na gumagalaw ang mga counter:
ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose
Ang nakikinig na socket ay sumasagot sa ibang tanong kaysa sa mga tuntunin. Kung walang nakikinig sa port, tinatanggihan ng kernel ang koneksyon at walang inbound na tuntunin ang may kaugnayan. Kung may socket at ang koneksyon mula sa malayong kliyente ay nag-expire, may pagtatapon na nagaganap sa isang lugar sa landas, at sinasabi ng mga counter ng tuntunin kung dito nangyayari.
Buksan ang logging para sa profile o chain na pinaghihinalaan mo sa halip na manghula mula sa labas. Ang isang naitalang pagtatapon na nagbabanggit ng source, destinasyon at port ay tumutukoy sa layer at tuntunin, at pinapatunayan din na nakarating ang packet, na hindi matatag ng anumang pagsubok sa panig ng kliyente.
Basahin ang pasya ng gateway kapag doon nagtatapos ang tunel
Sa gateway na site-to-site o remote access, ina-authenticate ng VPN ang gumagamit at pinapahintulutan ng patakaran ang resource, at magkahiwalay ang mga iyon. Ang gumagamit na pinapasok sa tunel ay hindi awtomatikong pinapasok sa bawat panloob na host, at ang pagtanggi ay madalas nagmumula sa tuntunin ng forwarding habang malusog ang tunel mismo. Ang parehong paghihiwalay ay lumilitaw sa IPsec, kung saan ang patakarang panseguridad na pumipili ng trapiko ay iba sa filter na pumapayag dito, at iyon ang dahilan kung bakit ang dalawa ay dokumentado bilang magkaibang mekanismo sa RFC 4301.
Suriin ang pabalik na landas nang kasing-ingat ng palabas. Kailangan makita ng stateful filtering ang sagot, kaya ang asymmetric routing sa tunel sa isang direksyon at sa paligid nito sa kabila ay gumagawa ng pagtatapon na mukhang random at umuulit lamang mula sa ilang kliyente. Kung umabot ang trapiko sa gateway at huminto, basahin ang tuntunin ng forwarding at ang pabalik na landas nang sabay bago palawakin ang anuman.
Ang gateway din ang lugar kung saan maaaring itago ng tuntunin ng NAT o masking ang tunay na source. Kung nakikita ng panloob na host ang address ng gateway sa halip na ang kliyente, hindi kailanman magtutugma ang kanilang mga tuntunin ng firewall ng host na dapat tumugma sa pool ng kliyente, at ang pagwawasto ay para sa gateway at hindi sa bawat server.
Baguhin ang pinakamakitid na layer, pagkatapos i-verify
Labanan ang malawak na pagkumpuni. Ang pagpatay sa firewall ng host, pagdaragdag ng tuntuning nagpapahintulot sa lahat, o pagpilit sa bawat interface sa pinagkakatiwalaang profile ay nag-aalis ng kontrol na gumagawa ng trabaho nito, at ang pagbabago ay mas matagal pa sa insidente. Ang tuntuning limitado sa saklaw ng source at sa port na pinag-uusapan ay mas madaling suriin, mas madaling alisin, at iniiwan ang natitirang patakaran ng makina na buo.
I-verify gamit ang parehong pagsubok na nabigo, mula sa parehong kliyente, at pagkatapos muli pagkatapos kumonekta muli, dahil ang tuntuning tumutugma bago muling makipagnegosasyon ang tunel ay maaaring tumigil sa pagtutugma pagkatapos:
nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/
Bago isara:
- Ang landas sa destinasyon ay lumalabas sa interface ng tunel, at ang source address ay tumutugma sa inaasahan ng patakaran.
- May nakikinig sa port, at ang pagtanggi o timeout ay iniuugnay sa pinangalanang tuntunin, hindi ipinapalagay.
- Nagpapasa ang gateway sa dalawang direksyon, at nakikita ng destinasyon ang source na pinaglaanan ng iyong mga tuntunin.
- Walang kontrol na pinatay para makapasa ang pagsubok, at ang pagbabagong ginawa mo ay nagbabanggit ng isang saklaw ng source at isang port.