VPN સર્વર માટે ક્લાઉડ ફાયરવોલ વિરુદ્ધ હોસ્ટ ફાયરવોલ

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

ધારથી શરૂ કરીને અંદર તરફ જાઓ

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

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

મહેમાનને સ્પર્શ કરતા પહેલાં ક્લાઉડ નીતિ વાંચો

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

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

પહેલાં લિસનર, પછી ઇનપુટ ચેઇન નિશ્ચિત કરો

ઇન્સ્ટન્સ પર તપાસો કે VPN પ્રક્રિયા તમે ધારેલા સરનામા અને પોર્ટ સાથે બંધાયેલી છે, ઉદાહરણ તરીકે ss -lntp 'sport = :1194' વડે. ફક્ત 127.0.0.1 સાથે બંધાયેલ ડેમન સ્થાનિક ક્લાયન્ટ સ્વીકારે છે અને ટનલ દ્વારા કંઈ જ નહીં, જે બહારથી હૂબહૂ ફિલ્ટર કરેલા પોર્ટ જેવું દેખાય છે.

પછી સ્થાનિક નિયમો એ જ વાક્યરચનામાં વાંચો જે તમે તેમને બદલવા માટે વાપરો છો, જેમ કે iptables -S INPUT અથવા nft list chain inet filter input. ફાઇલમાં લખાયેલો પણ કદી લોડ ન કરેલો નિયમ, અથવા મેળ ખાતી મંજૂરી વગરનું ડિફોલ્ટ ડ્રોપ, પેકેટને ચૂપચાપ ફેંકી દે છે. ફોરવર્ડિંગ ગેટવે માટે ફોરવર્ડિંગ અને રિવર્સ-પાથ સેટિંગ્સ પણ તપાસો. ઇન્સ્ટન્સ સરનામાં પર મોકલાયેલા નહીં પણ તેમાંથી રૂટ થતા પેકેટનું શું થાય તે આ નક્કી કરે છે.

એક સ્તરમાં સ્ટેટફુલ, બીજામાં સ્ટેટલેસ

સિક્યોરિટી ગ્રુપ પોતે મંજૂર કરેલા પ્રવાહો યાદ રાખે છે અને જવાબો પાછા આવવા દે છે. સબનેટ એક્સેસ કંટ્રોલ લિસ્ટ અને ઘણા હોસ્ટ ફાયરવોલ આવી સ્થિતિ રાખતા નથી, તેથી ફક્ત આઉટબાઉન્ડ દિશા આવરી લેતો નિયમ વિનંતીને પસાર કરે છે અને જવાબ ફેંકી દે છે. બીજા સ્તરનો નિયમ વાંચ્યા વગર સ્તરો વચ્ચે પરત-ટ્રાફિકની ધારણા કદી ન લઈ જાઓ (second layer's rule).

ખાતાના દરેક નિયમને વાંચવા કરતાં કાઉન્ટર ઝડપથી નિર્ણય કરે છે. વધતું કાઉન્ટર એટલે પેકેટ ત્યાં પહોંચ્યું અને ત્યાં જ ફેંકાયું, જ્યારે શૂન્ય પર થીજેલું કાઉન્ટર એટલે તે ત્યાં સુધી કદી પહોંચ્યું જ નહીં; નિયમો કાઉન્ટર સાથે લોડ થયા હોય ત્યારે iptables -vnL INPUT અને nft list ruleset તે આંકડા દર્શાવે છે.

જીવંત નહીં, નવા સત્ર સાથે પરીક્ષણ કરો

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

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