firewalld લિસનર નિયમ વિરુદ્ધ ફોરવર્ડિંગ નીતિ: દરેક શું કરે છે

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

બે નીતિઓ, એક ટ્યુનલ

બહારની નીતિ એક સરળ પ્રશ્નનો જવાબ આપે છે: આ સ્રોતમાંથી આવતું પેકેટ આ હોસ્ટ પર UDP 1194 સુધી પહોંચી શકે છે? અંદરની નીતિ બીજા પ્રશ્નનો જવાબ આપે છે: તે ટ્યુનલ પાછળનો પ્રમાણિત ક્લાયન્ટ આ ગંતવ્ય સુધી, આ પ્રોટોકોલ સાથે, આ પોર્ટ પર પહોંચી શકે છે? પહેલી સોકેટ વિશે છે, બીજી માર્ગ વિશે છે, અને firewalld તેમને અલગ ઑબ્જેક્ટ સાથે મોડેલ કરે છે કારણ કે તે અલગ બિંદુઓ પર નક્કી થાય છે. એક આ હોસ્ટ પરના સોકેટનો ગુણધર્મ છે, બીજો તેમાંથી પસાર થતા માર્ગનો.

વ્યવહારુ પરિણામ એ છે કે કામ કરતું ટ્યુનલ બીજી નીતિ વિશે કંઈ કહેતું નથી, અને સાચી બીજી નીતિ પહેલીને બિનજરૂરી બનાવતી નથી.

વાસ્તવિક બહારના લિસનરને મંજૂર કરો

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

જો લિસનર ખરેખર તે ઝોન પર UDP 1194 છે, તો તે પોર્ટ અને ટ્રાન્સપોર્ટ ખાસ ખોલો, પછી પરીક્ષણ કર્યા પછી તે જ ચોક્કસ નિયમને કાયમી બનાવો. સ્રોત-આધારિત ફાળવણીઓ પણ તપાસો, કારણ કે સ્રોત શ્રેણી સાથે બંધાયેલો ઝોન ઇન્ટરફેસ ઝોન તેને જોવાના પહેલાં જ ટ્રાફિક પકડી શકે છે.

ડિક્રિપ્ટ થયેલા ગંતવ્યને અલગથી અધિકૃત કરો

VPN સર્વર પર જ ચાલતી સેવા સાથેનું જોડાણ સ્થાનિક-ઇનપુટ નીતિ છે. LAN માં બીજા હોસ્ટ પર ફોરવર્ડ કરાયેલા જોડાણને ફોરવર્ડિંગ નીતિની જરૂર છે, કર્નલમાં સક્ષમ ફોરવર્ડિંગ અને પ્રતિસાદ માર્ગ — આ ત્રણ અલગ આવશ્યકતાઓ છે જેને લોકો સામાન્ય રીતે એકમાં ભેગી કરે છે. આધુનિક firewalld નીતિ ઑબ્જેક્ટ ઇનગ્રેસ ઝોન અને એગ્રેસ ઝોન વચ્ચેના નિર્દેશિત ટ્રાફિકનું વર્ણન કરે છે, અને કયા VPN સ્રોત કઈ ખાનગી સેવાઓ સુધી પહોંચી શકે તે વ્યક્ત કરવાની યોગ્ય જગ્યા એ જ છે.

મંજૂર સ્રોતોને સ્પષ્ટ રીતે વ્યાખ્યાયિત કરો અને બાકીનું બધું નકારમાં પડવા દો. બહારની સેવા માટેની પરવાનગી તે નીતિ નથી, ઝોનની ગોઠવણ કેવી પણ દેખાય.

કેમ ઇન્ટરફેસ પર ભરોસો મૂકવો ખોટો ટૂંકો રસ્તો છે

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

ટ્યુનલની ઝોન ફાળવણીને જે પણ ઘટક તે કન્ફિગરેશન ધરાવે છે તેના દ્વારા સ્થિર રાખો. રીસ્ટાર્ટ પર ફાળવણી ગુમાવવાથી એવી નિષ્ફળતા થાય છે જે ફાયરવોલ નિયમની સમસ્યા જેવી લાગે છે અને વાસ્તવમાં સ્થિરતાની સમસ્યા છે.

ત્રણ વસ્તુઓ ચકાસો, જેમાં એક નકાર પણ

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

સર્વરની નોંધમાં ઝોન, પોર્ટ, ટ્રાન્સપોર્ટ અને નીતિ ઑબ્જેક્ટ લખો. નહીં તો આ હોસ્ટ પરનો આગલો ફેરફાર એ જ ધારણાથી શરૂ થશે.