VPN માટે ક્લાઉડ સિક્યોરિટી ગ્રુપ: લિસનર ખોલો, બધું નહીં

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

નિયમ પહેલા પ્રોટોકોલનું નામ આપો

નિયમ એટલે પ્રોટોકોલ, પોર્ટ રેન્જ અને સ્રોત. WireGuard UDP પર સાંભળે છે, સામાન્ય રીતે 51820. OpenVPN સામાન્ય રીતે UDP અથવા TCP 1194 હોય છે, તે કેવી રીતે ગોઠવાયું છે તેના પર આધાર રાખે છે. IPsec ને UDP 500 અને 4500 પર IKE વિનિમય જોઈએ છે, ઉપરાંત ESP પ્રોટોકોલ પોતે, જે પોર્ટ નહીં પણ પ્રોટોકોલ નંબર છે. બીજા નિયમો TCP છે એટલે TCP ધારવું એ એવો નિયમ બનાવે છે જે સાચો લાગે પણ કંઈપણ સાથે મેળ ખાતો નથી.

લિસનર ચાલુ સેવામાંથી વાંચો, ટ્યુટોરિયલમાંથી નહીં. એક સરનામા સાથે બંધાયેલ ડેમન બીજા સરનામે આવતું ટ્રાફિક સ્વીકારશે નહીં.

સ્રોતને આખા ઇન્ટરનેટને બદલે ડિઝાઇન મંજૂર કરે તે ક્લાયન્ટ રેન્જ સુધી મર્યાદિત કરો.

સિક્યોરિટી ગ્રુપ સ્ટેટફુલ છે; સબનેટ ACL નહીં

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

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

અસરકારક પોલિસી એ જોડાયેલાનો સંઘ છે, તમે સંપાદિત કરેલી ફાઇલ નહીં.

હોસ્ટ ફાયરવોલ અલગ સીમા છે

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

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

ઇન્ટરફેસ પરનું કેપ્ચર તમને કહે છે કે કઈ સીમાએ પેકેટ ફેંક્યો.

લિસનરને મંજૂરી આપવી એ ક્લાયન્ટ્સને રૂટ કરવું નથી

ક્લાયન્ટ ટ્રાફિક ફોરવર્ડ કરતા VPN ગેટવેને ખુલ્લા પોર્ટ કરતાં વધુ જોઈએ છે. તેને IP ફોરવર્ડિંગ, ટનલ ઇન્ટરફેસથી ગંતવ્ય નેટવર્ક સુધીના ફ્લોને મંજૂર કરતી પોલિસી, અને ઘણી વાર ઇન્ટરફેસ પર સ્રોત-ગંતવ્ય તપાસ બંધ કરેલી જરૂરી છે જેથી પ્લેટફોર્મ તેના પર ઉલ્લેખ ન કરેલું ટ્રાફિક ફેંકી ન દે. એમાંથી કંઈપણ લિસનર નિયમ બનાવતો નથી.

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

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

પાછા ફરવાનો માર્ગ રાખો, પછી નિયમ સાંકડો કરો

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

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

જોડાણનું પણ દસ્તાવેજીકરણ કરો, નહીંતર બદલીનારું ઇન્ટરફેસ શાંતિથી પોલિસી ગુમાવશે.