લિનક્સ વિતરણનો ફાયરવોલ તમારા VPN ટ્રાફિકને અવરોધી શકે છે
બે ફિલ્ટર મેનેજર, એક નિયમસેટ અને ખોટા ઝોનમાં ઉતરતી ટનલ. કોઈપણ નિયમ ઉમેરતા પહેલાં માલિક અને દિશા નક્કી કરો.
ટનલ ઉપર આવે છે, લોગ કહે છે જોડાયેલ છે, અને એક એપ્લિકેશન હજી પણ કંઈપણ સુધી પહોંચી શકતી નથી. લિનક્સ ક્લાયન્ટ પર તેનો સામાન્ય અર્થ એ છે કે વિતરણનો ફાયરવોલ એવો માર્ગ ફિલ્ટર કરે છે જે VPN ક્લાયન્ટે કદી સંચાલિત કર્યો નથી. બે મેનેજર એકસાથે સક્રિય હોઈ શકે છે, દરેકની ઇન્ટરફેસ, ઝોન અને ટ્રાફિકની દિશા વિશે પોતાની કલ્પના હોય છે. કંઈપણ સંપાદિત કરતા પહેલાં માલિક ઓળખવો નિયમો અજમાવીને કંઈક કામ થાય ત્યાં સુધી રાહ જોવા કરતાં ઝડપી છે.
મેનેજર અને બેકએન્ડ શોધો
જે ખરેખર લોડ થયું છે તેનાથી શરૂ કરો, જે ઇન્સ્ટોલ થયું છે તેનાથી નહીં. વિતરણ firewalld, ufw અને સામાન્ય nftables સેવા સાથે આવી શકે છે, અને તેમાંથી ફક્ત એક જ ચાલતા નિયમસેટનો માલિક છે. પેકેજો શાંતિથી સાથે રહે છે, અને ખોટા ફ્રન્ટએન્ડ દ્વારા દાખલ કરાયેલો નિયમ ક્યારેય કર્નલ સુધી પહોંચતો નથી. સક્રિય સેવા વાંચો, પછી તેણે બનાવેલો નિયમસેટ વાંચો.
બેકએન્ડ ફ્રન્ટએન્ડ જેટલું જ મહત્વનું છે. firewalld ઇન્સ્ટોલેશન આવૃત્તિ અને રૂપરેખાંકનના આધારે nftables અથવા જૂના iptables બેકએન્ડને ચલાવી શકે છે, અને બંને અલગ નિરીક્ષણ આઉટપુટ આપે છે. તમારી સિસ્ટમને કોઈપણ માર્ગદર્શિકા સાથે સરખાવતા પહેલાં વિતરણ, આવૃત્તિ અને બેકએન્ડ ટિકિટમાં લખો.
દિશા અને ઇન્ટરફેસ મેળવો
બહાર જતી ક્લાયન્ટ વિનંતી, અંદર આવતો શ્રોતા અને ફોરવર્ડ થયેલો પેકેટ અલગ અલગ હૂકમાંથી પસાર થાય છે, અને એક માટેનો નિયમ બીજાને આવરી લેતો નથી. સ્થાનિક LAN ને મંજૂરી આપતા ઝોનમાં ઘણી વાર ટનલ ઇન્ટરફેસ કે VPN સરનામા પૂલ હોતો નથી. ટનલ ઇન્ટરફેસ સામાન્ય રીતે ડિફોલ્ટ ઝોનમાં ઉતરે છે, જે ઘણી વાર ભૌતિક એડેપ્ટરના ઝોન કરતાં વધુ કડક હોય છે. આ અસંગતિ સમજાવે છે કે કેમ LAN પર બ્રાઉઝિંગ કામ કરે છે અને ટનલ ઉપર આવતાની ક્ષણે જ અટકી જાય છે.
નિયમ પસંદ કરતા પહેલાં પૂછો કે કઈ દિશા નિષ્ફળ ગઈ. જે એપ્લિકેશન બહાર જોડાઈ શકતી નથી તેને આઉટપુટ માર્ગની જરૂર છે, જ્યારે અંદર આવતી સેવાને ટનલ ઇન્ટરફેસ પર ઇનપુટ માર્ગની જરૂર છે. ખોટી ચેઇનમાં નિયમ ઉમેરવાથી એવો ફેરફાર થાય છે જે લાગુ થયેલો દેખાય છે અને કંઈ જ કરતો નથી.
નિયમોના માલિકોને સહમત રાખો
VPN ક્લાયન્ટનો હૂક, કન્ટેનર રનટાઇમ અને વિતરણની સેવા બધા નેટવર્કિંગ બદલી શકે છે, અને તેઓ એકબીજા સાથે સંકલન કરતા નથી. હાથે દાખલ કરેલા નિયમો આગલા રીલોડ પર અદૃશ્ય થઈ જાય છે, અને મેનેજરની ચેઇનમાં દાખલ કરેલા નિયમો તમે ન ધાર્યો હોય તેવા ક્રમમાં મૂલ્યાંકન પામી શકે છે. મેનેજરની સ્થાયી રૂપરેખાંકનનો ઉપયોગ કરો અને તમે લખેલી ફાઇલને બદલે પરિણામી નિયમસેટનું નિરીક્ષણ કરો. એક સેવા પહોંચમાં નથી તે કારણે આખો ફાયરવોલ બંધ કરવો નાની સમસ્યાના બદલે મોટી સમસ્યા લાવે છે.
સાંકડા કાઉન્ટર નકારાયેલા પ્રવાહને શોધવાનો સસ્તો રસ્તો છે. એક ગંતવ્ય અને એક પોર્ટ સુધી મર્યાદિત લોગિંગ નિયમ બતાવે છે કે ડ્રોપ સ્થાનિક રીતે થાય છે કે નહીં, બીજાનો ટ્રાફિક પકડ્યા વિના. તપાસ પૂરી થાય ત્યારે લોગિંગ નિયમ દૂર કરો, કારણ કે તે નીતિ નહીં પણ નિદાન છે, અને firewalld નું ઝોન દસ્તાવેજીકરણ સમજાવે છે કે ઇન્ટરફેસ અને સેવાઓ કેવી રીતે જોડાય છે.
લોકડાઉન ગુમાવ્યા વિના સુધારો ચકાસો
લાગુ થયેલી સ્થિતિનું નિરીક્ષણ તેના માલિક મેનેજર સાથે કરો, તમે નોંધેલા બેકએન્ડ સાથે મેળ ખાતા આદેશોનો ઉપયોગ કરીને. નીચેની સૂચિ ધારે છે કે firewalld જવાબદાર છે; બધા ચલાવવાને બદલે nftables અથવા ufw માટે સમકક્ષ મૂકો. એક સત્રમાં સાધનો ભેળવવા એ જ રીતે મશીન બે વિરોધાભાસી નિયમસેટ સાથે પૂરું થાય છે.
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40
પ્રથમ આદેશ ઝોન અને તેમને ફાળવેલા ઇન્ટરફેસનાં નામ આપે છે, જે દર્શાવે છે કે ટનલ ખરેખર ક્યાં ઉતરી. બીજો ઝોનના નિયમો અને સેવાઓ છાપે છે, જેથી તમે જોઈ શકો કે VPN ઇન્ટરફેસ બિલકુલ આવરી લેવાયો છે કે નહીં. nftables સૂચિ વપરાતા બેકએન્ડ માટે મૂળભૂત સત્ય છે, અને ફક્ત રૂપરેખાંકન ફાઇલમાં રહેલો નિયમ ત્યાં દેખાતો નથી. ત્રણેય આઉટપુટને તમે ઉમેરેલા નિયમ સાથે સરખાવો, અને અસંગતિ સામાન્ય રીતે પોતાનું નામ જ કહી દે છે.
પછી મૂળ વિનંતી અને તમે માગતા નિષ્ફળતાના વર્તનને પુનરાવર્તિત કરો. નવું કામ કરતું સાઇટ પૂરતું નથી જો એ જ ફેરફારે ક્લાયન્ટનું લોકડાઉન દૂર કર્યું હોય, તેથી અસુરક્ષિત માર્ગ પણ ચકાસો. મેનેજર, બેકએન્ડ, ઇન્ટરફેસ અને નિયમનો હેતુ નોંધો, કારણ કે બીજા મેનેજરને પુનર્જીવિત કરતું પેકેજ અપડેટ નહીં તો આખું વાવાઝોડું ફરી ઊભું કરશે.