OpenVPN ક્લાયન્ટ બ્લોક નિયમ કેમ ક્યારેય FORWARD સુધી પહોંચતો નથી

એક જ OpenVPN સર્વર પરના બે ક્લાયન્ટ તેમના પૂલ માટે DROP નિયમ ઉમેર્યા પછી પણ એકબીજા સુધી પહોંચી શકે છે. નિયમ FORWARD ચેઇનમાં બેસે છે, ટ્રાફિક સ્પષ્ટપણે વહે છે, અને તે નિયમનું કાઉન્ટર શૂન્ય પર જ રહે છે. સ્વાભાવિક તારણ એ છે કે ફાયરવોલ તૂટેલી છે. મોટાભાગે પેકેટ ચેઇનમાં આવ્યું જ નથી.

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

પીઅર પેકેટ જઈ શકે તેવા બે રસ્તા

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

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

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

જ્યારે કાઉન્ટર ક્યારેય ખસતું નથી

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

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

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

ફિલ્ટર કરી શકે તેવી સીમા પસંદ કરવી

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

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

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

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

નિયમ પર ભરોસો કરવાને બદલે આઇસોલેશન ચકાસવું

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

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

આઇસોલેશન એ તે સીમા પરનું અવલોકિત પરિણામ છે જે ખરેખર પ્રવાહ વહન કરે છે. હોસ્ટમાં ક્યાંયનો DROP નિયમ પુરાવો નથી; નિષ્ફળ કનેક્શન અને તેને કારણભૂત નિયમનું ખસેલું કાઉન્ટર એ પુરાવો છે.