Walang nagawa ang ufw allow 443 para sa serbisyong nasa likod ng VPN

Tagumpay ang ping mula sa isang kliyente ng VPN, nag-time out ang serbisyong TCP, at wala talagang binabago ang ufw allow 443/tcp. Kapag tumatakbo ang aplikasyon sa isang host sa likod ng gateway at hindi sa gateway mismo, isinulat ang permiso para sa maling landas ng trapiko. Hindi nakadiriha ang packet sa firewall at hindi ito naipapasa sa anumang lokal na proseso, kaya hindi ito nakikita ng mga patakaran sa papasok. Ang lunas ay isang patakaran sa ruta na nakatutok sa ipinapasang daloy, at ang ebidensiya nito ay nasa log na.

Magpasya kung ang destinasyon ay lokal o ipinapasa

Basahin ang packet ayon sa nakikita ng kernel. Ang trapikong naipapasa sa isang serbisyo sa gateway ay lokal na papasok. Ang trapikong ipinapasa ng gateway sa ibang host ay ipinapasa, at may hiwalay na mga set ng patakaran ang UFW para sa dalawang landas. Ang pagkakaiba ay pinagpapasyahan ng destinasyong address at ng paghahanap ng ruta, hindi ng interface kung saan dumating ang packet.

Ang linyang log na nagpapakita ng parehong interface sa dalawang field na IN at OUT ay maaari pa ring ilarawan ang isang rutang packet, dahil ang lagusan na nagdadala ng mga kliyente papasok at palabas ng isang aparato ay ganito talaga ang hitsura. Mas mabilis na inaayos ng destinasyong address ang tanong na iyon kaysa sa mga pangalan ng interface. Ang makita ang parehong pangalan nang dalawang beses ay hindi nagpapatunay ng lokal na paghahatid, at ang pag-imbento ng interface ng lagusan na hindi kailanman ginawa ng deployment ay hindi rin nakakatulong.

Basahin ang block bago magdagdag ng anumang patakaran

Ulitin ang isang awtorisadong pagtatangkang kumonekta at itala ang pinagmulan, destinasyon, protocol at destinasyong port nito ayon sa naitala ng gateway. Ihambing ang apat na halagang iyon sa tala sa log at sa aktuwal na lokasyon ng serbisyo. Ang naunang matagumpay na ping ay nagpapatunay lamang na pinayagan ang sarili nitong pagpapalitan, at maaaring ibang-iba ang pagtrato ng firewall sa isang TCP SYN papunta sa isang aplikasyon.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Ibinabalik ng unang utos ang hatol kasama ang mga field nito, at ipinapakita ng pangalawa kung ano ang nakapasok na at sa anong ayos. Basahin ang dalawa bago mag-edit ng kahit ano, dahil ang naunang pagtanggi sa itaas ng iyong patakaran ay nagpapaliwanag ng parehong sintomas nang walang anumang kulang na patakaran.

Isulat ang pinakamakipot na patakaran sa ruta na umaangkop

Sa halimbawang ito dumarating ang mga kliyente sa tun0 mula sa 172.20.8.0/24, nakikinig ang serbisyo sa 10.30.0.15 sa port 8443, at lumalabas ang gateway sa ens5. Pinili ang mga halagang iyon para hindi ito magmukhang default ng cloud VPC na 10.0.0.0/16 o network sa bahay na 192.168.0.0/16, at inilalayo ng 8443 ang halimbawa sa sariling tagapakinig na 443 ng gateway.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Ipinapakita ng dry run ang set ng patakarang mabubuo, at iyon ang pinakamurang paraan upang makita kung bago o pagkatapos ng umiiral na pagtanggi mahuhulog ang patakaran mo. Tiyakin ang mga pangalan ng interface at mga panloob na address laban sa deployment at hindi laban sa halimbawa, at tandaan na kapag nauna ang NAT ng destinasyon, nakikita ng filter ang naisaling destinasyon.

Panatilihing may estado ang daan pabalik

Sinusubaybayan ng UFW ang mga pinapayagang koneksyon, kaya tinatanggap ang mga sagot sa isang pinapayagang ipinapasang daloy nang walang tahasang kabaligtarang patakaran. Ang pagdaragdag ng walang limitasyong patakaran sa kabaligtarang direksyon upang gumana ang mga bagay ay nagpapalawak ng patakaran nang malayo sa nag-iisang serbisyo at hindi kailangan para sa normal na pagpapalitan ng kahilingan at sagot. Panatilihing implicit ang daan pabalik at nababasa ang set ng patakaran.

Ilapat lamang ang patakaran kapag tumugma ang dry run sa iyong layunin, pagkatapos ay tiyakin na ipinapakita ito ng nakaayos na listahan sa inaasahang posisyon. Panatilihing hiwalay na usapin ang tagapakinig ng VPN at ang mga patakaran sa pamamahala, dahil ang pagbabago sa mga iyon ay ibang desisyon kaysa sa pagpayag sa isang aplikasyon. Itala ang pagbabago sa parehong lugar kung saan nakasulat ang topolohiya, upang hindi na kailangang tuklasin itong muli ng susunod na inhinyero mula sa pagkuha ng packet.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Suriin kung ano ang hindi kayang ipatupad ng UFW para sa iyo

Ang tamang patakaran ay nangangailangan pa rin ng pagpapasa sa kernel at ng rutang umaabot sa serbisyo. Tiyakin ang dalawa bago sisihin ang firewall sa ikalawang pagkakataon.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Pagkatapos ay tumingin sa labas ng host. Sa isang cloud instance, hindi pinapalitan ng patakaran ng UFW ng bisita ang mga security group, subnet ACL o ang sariling konfigurasyon ng pagpapasa ng provider, kaya ang lokal na pagharang ay ebidensiya tungkol sa isang layer at hindi patunay na pinapayagan ng lahat ng ibang layer ang serbisyo.

Tapusin sa pagsubok ng bagong koneksyon habang bukas ang firewall, mula sa pinapayagang pinagmulan at mula sa hindi kaugnay. Ang pag-disable ng UFW ay nag-aalis ng sintomas at sumisira ng ebidensiya sa iisang utos, kaya dapat itong huling eksperimento at hindi ang una.