VPN પાછળની સેવા માટે ufw allow 443 એ કંઈ કર્યું નહીં

VPN ક્લાયન્ટમાંથી ping સફળ થાય છે, TCP સેવા સમયસીમા વટાવી જાય છે, અને ufw allow 443/tcp કંઈપણ બદલતું નથી. જ્યારે એપ્લિકેશન ગેટવે પર જ નહીં પણ ગેટવે પાછળના હોસ્ટ પર ચાલે છે, ત્યારે એ પરવાનગી ખોટા ટ્રાફિક માર્ગ માટે લખાયેલી હતી. પેકેટ ફાયરવોલને સંબોધાયેલું નથી અને સ્થાનિક પ્રક્રિયાને પહોંચાડાતું નથી, તેથી ઇનપુટ નિયમો તેને કદી જોતા નથી. ઉપાય એ ફોરવર્ડ થતા પ્રવાહ પર લક્ષ્ય રાખતો રૂટ નિયમ છે, અને તેનો પુરાવો પહેલેથી લોગમાં છે.

ગંતવ્ય સ્થાનિક છે કે ફોરવર્ડ, તે નક્કી કરો

કર્નલ જેમ જુએ છે તેમ પેકેટ વાંચો. ગેટવે પરની સેવાને પહોંચાડાતો ટ્રાફિક સ્થાનિક આવક છે. ગેટવે બીજા હોસ્ટ તરફ મોકલતો ટ્રાફિક ફોરવર્ડ છે, અને UFW બંને માર્ગો માટે અલગ નિયમસેટ રાખે છે. આ ભેદ ગંતવ્ય સરનામું અને રૂટિંગ શોધ નક્કી કરે છે, પેકેટ કઈ ઇન્ટરફેસ પર આવ્યું તે નહીં.

IN અને OUT બંને ફીલ્ડમાં એક જ ઇન્ટરફેસ દર્શાવતી લોગ લાઇન હજુ પણ રાઉટેડ પેકેટનું વર્ણન કરી શકે છે, કારણ કે એક જ ઉપકરણમાંથી ક્લાયન્ટને અંદર-બહાર લઈ જતી ટનલ બરાબર એવી જ દેખાય છે. ગંતવ્ય સરનામું ઇન્ટરફેસ નામો કરતાં આ પ્રશ્ન વધુ ઝડપથી હલ કરે છે. એક જ નામ બે વાર જોવું સ્થાનિક ડિલિવરી સાબિત કરતું નથી, અને ડિપ્લોયમેન્ટે કદી બનાવ્યું ન હોય તેવું ટનલ ઇન્ટરફેસ શોધી કાઢવાથી પણ મદદ મળતી નથી.

કોઈપણ નિયમ ઉમેરતા પહેલા બ્લોક વાંચો

એક અધિકૃત જોડાણ પ્રયાસ ફરી ચલાવો અને ગેટવેએ નોંધ્યા તેમ તેનું સ્રોત, ગંતવ્ય, પ્રોટોકોલ અને ગંતવ્ય પોર્ટ કેપ્ચર કરો. એ ચાર મૂલ્યોની લોગ એન્ટ્રી અને સેવાના વાસ્તવિક સ્થાન સાથે સરખામણી કરો. અગાઉનું સફળ ping ફક્ત એ સાબિત કરે છે કે તેની પોતાની આપલેને પરવાનગી હતી, અને ફાયરવોલ એપ્લિકેશન તરફના TCP SYN સાથે સાવ અલગ રીતે વર્તી શકે છે.

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

પહેલો આદેશ ચુકાદો તેના ફીલ્ડ સાથે પરત આપે છે, અને બીજો દર્શાવે છે કે શું પહેલેથી લોડ થયેલું છે અને કયા ક્રમમાં. કંઈપણ સંપાદિત કરતા પહેલા બંને વાંચો, કારણ કે તમારા નિયમની ઉપરનું અગાઉનું નકાર કોઈ ખૂટતા નિયમ વિના પણ એ જ લક્ષણ સમજાવે છે.

બંસતો સૌથી સાંકડો રૂટ નિયમ લખો

આ ઉદાહરણમાં ક્લાયન્ટ 172.20.8.0/24 થી tun0 પર આવે છે, સેવા 8443 પોર્ટ પર 10.30.0.15 પર સાંભળે છે, અને ગેટવે ens5 થી બહાર જાય છે. એ મૂલ્યો એટલા માટે પસંદ કરાયા છે કે તે ક્લાઉડ VPC ના ડિફોલ્ટ 10.0.0.0/16 કે ઘરના 192.168.0.0/16 જેવા બિલકુલ ન લાગે, અને 8443 ઉદાહરણને ગેટવેના પોતાના 443 શ્રોતાથી દૂર રાખે છે.

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

ડ્રાય રન પરિણામરૂપ નિયમસેટ છાપે છે, અને તમારો નિયમ હાલના નકાર પહેલાં પડે છે કે પછી તે જોવાનો આ સૌથી સસ્તો રસ્તો છે. ઇન્ટરફેસ નામો અને આંતરિક સરનામાં ઉદાહરણ સાથે નહીં પણ ડિપ્લોયમેન્ટ સાથે તપાસો, અને યાદ રાખો કે જ્યારે ગંતવ્ય NAT પહેલાં ચાલે ત્યારે ફિલ્ટર અનુવાદિત ગંતવ્ય જુએ છે.

પરત માર્ગને સ્થિતિસહ રાખો

UFW મંજૂર જોડાણો પર નજર રાખે છે, તેથી મંજૂર ફોરવર્ડ પ્રવાહના જવાબો સ્પષ્ટ વિરુદ્ધ નિયમ વિના સ્વીકારાય છે. વસ્તુઓ ચાલે તે માટે વિરુદ્ધ દિશામાં અમર્યાદિત નિયમ ઉમેરવાથી નીતિ એક જ સેવાથી ઘણી આગળ વિસ્તરે છે અને સામાન્ય વિનંતી-જવાબ આપલે માટે તેની જરૂર નથી. પરત માર્ગને ગર્ભિત અને નિયમસેટને વાંચવાલાયક રાખો.

ડ્રાય રન તમારા ઇરાદા સાથે મેળ ખાય ત્યારે જ નિયમ લાગુ કરો, પછી ખાતરી કરો કે ક્રમબદ્ધ યાદી તેને અપેક્ષિત જગ્યાએ દર્શાવે છે. VPN શ્રોતા અને સંચાલન નિયમોને અલગ બાબતો તરીકે જાળવો, કારણ કે તેમને બદલવું એક એપ્લિકેશનને મંજૂરી આપવા કરતાં અલગ નિર્ણય છે. ટોપોલોજી જ્યાં લખાયેલી છે ત્યાં જ ફેરફાર નોંધો, જેથી આગલા ઇજનેરને પેકેટ કેપ્ચરમાંથી તે ફરી શોધવું ન પડે.

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

UFW તમારા વતી શું લાગુ કરી શકતું નથી તે તપાસો

સાચા નિયમને હજુ પણ કર્નલ ફોરવર્ડિંગ અને સેવા સુધી પહોંચતા રૂટની જરૂર છે. ફાયરવોલને બીજી વાર દોષ આપતા પહેલા બંનેની ખાતરી કરો.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

પછી હોસ્ટની બહાર જુઓ. ક્લાઉડ ઇન્સ્ટન્સ પર અતિથિની UFW નીતિ સિક્યોરિટી ગ્રુપ, સબનેટ ACL કે પ્રોવાઇડરના પોતાના ફોરવર્ડિંગ રૂપરેખાંકનને બદલતી નથી, તેથી સ્થાનિક બ્લોક એક સ્તર વિશેનો પુરાવો છે, બીજા બધા સ્તરો સેવાને મંજૂરી આપે છે તેનો પુરાવો નહીં.

ફાયરવોલ ચાલુ રાખીને નવું જોડાણ ચકાસીને પૂર્ણ કરો, એક મંજૂર સ્રોતથી અને એક અસંબંધિત સ્રોતથી. UFW બંધ કરવાથી એક જ આદેશમાં લક્ષણ દૂર થાય અને પુરાવો નષ્ટ થાય, તેથી તે પહેલું નહીં પણ છેલ્લું પ્રયોગ હોવું જોઈએ.