VPN ચાલુ હોય ત્યારે ક્લાઉડ ફાયરવોલ કયું સરનામું જુએ છે
સંપૂર્ણ ટનલ તમારું ડેટાબેઝ જે સ્રોત સરનામું જુએ છે તે બદલે છે. મંજૂર સૂચિ, ખાનગી માર્ગ કે સ્પ્લિટ ટનલ ખસેડો, ઓળખપત્ર નહીં.
VPN જોડાય તે પહેલાં કામ કરતું અને પછી નિષ્ફળ જતું ડેટાબેઝ ભાગ્યે જ ઓળખપત્રની સમસ્યા હોય છે. ક્લાઉડ ફાયરવોલ સ્રોત સરનામાં મેળવે છે, અને સંપૂર્ણ ટનલ તે જ સરનામું બદલી નાખે છે જે તેઓ મેળવતા હતા. તમારું લેપટોપ શું મોકલે છે એવું તમે માનો છો અને સર્વર શું મેળવે છે તે વચ્ચેનું અંતર એ જ આખી ખામી છે, અને તે એક પગલામાં માપી શકાય છે.
સ્રોત સરનામું શું બને છે
સંપૂર્ણ ટનલમાં દરેક પેકેટ VPN ગેટવે થઈને બહાર નીકળે છે, તેથી સર્વર તમારા ઘરના જોડાણને બદલે ગેટવેનું આઉટબાઉન્ડ સરનામું જુએ છે. જો માર્ગમાં ફોરવર્ડ પ્રોક્સી હોય, તો તેનું સરનામું પહોંચે છે. બંને કાયદેસર સ્રોત છે, અને તમારા મૂળ નિયમમાંનું સરનામું એમાંથી કોઈ નથી.
Azure SQL ના સર્વર-સ્તર અને ડેટાબેઝ-સ્તરના ફાયરવોલ નિયમો તે ક્લાઇન્ટ સરનામું મેળવે છે જે લોજિકલ સર્વર સુધી પહોંચે છે, જે સંપૂર્ણ ટનલ પછી આઉટબાઉન્ડ સરનામું હોય છે. એક જ સરનામું મંજૂર કરતું AWS સુરક્ષા જૂથ પણ એ જ રીતે વર્તે છે. પેકેટ પ્રમાણીકરણ પહેલાં જ કાઢી નાખવામાં આવે છે, તેથી તમને મળતી ભૂલ પરવાનગીની સમસ્યાને બદલે નેટવર્ક નિષ્ફળતા જેવી લાગે છે. એટલે જ લોકો પાસવર્ડ ફરી સેટ કરવા લાગે છે.
મંજૂર સૂચિ ક્યાં નક્કી થાય છે
નિષ્ફળ જતા માર્ગ સાથે મેળ ખાતો નિયમ વાંચો, તમે બનાવ્યો હોય એવું યાદ છે તે નિયમ નહીં. તેની વ્યાપ્તિ, તેનો પોર્ટ, તેનો પ્રોટોકોલ અને કોઈપણ ઓળખ ચકાસણી પહેલાં તેનું મૂલ્યાંકન થાય છે કે નહીં તે નોંધો.
પછી નક્કી કરો કે કયો સ્તર કાયદેસર રીતે આ નિર્ણય ધરાવે છે. સરનામાનો નિયમ જવાબ આપે છે કે ટ્રાફિક ક્યાંથી આવે છે. ખાનગી એન્ડપોઇન્ટ જવાબ આપે છે કે સેવા ખાનગી માર્ગે જ પહોંચી શકાય છે કે નહીં. સ્પ્લિટ-ટનલ અપવાદ જવાબ આપે છે કે કયા લક્ષ્યો ટનલને ટાળે છે. આ અદલાબદલી કરી શકાય તેવા નથી, અને ટનલ બદલાય ત્યારે દરેક અલગ રીતે નિષ્ફળ જાય છે.
ત્રણ સુધારા, ત્રણ સ્તર
નીચેનો દરેક વિકલ્પ અલગ કારણસર પ્રવાહ સુધારે છે, અને ખોટો પસંદ કરવાથી એવું જોડાણ બને છે જે આગલા ગેટવે ફેરફાર સુધી કામ કરે છે.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
આઉટબાઉન્ડ સરનામું ઉમેરવું એ સૌથી નાનો ફેરફાર અને સૌથી નાજુક છે, કારણ કે નવો ગેટવે કે બીજો પ્રદેશ તેને ચૂપચાપ અમાન્ય કરી દે છે. ટનલની વ્યાખ્યા પાસે સરનામું દસ્તાવેજ કરો જેથી બંને સાથે ખસે. કામચલાઉ પહોળી શ્રેણી નિદાન છે, સુધારો નહીં; તેને જ્યાં છે ત્યાં રહેવા દેવું એ જ રીતે આંતરિક સેવાઓ ખુલ્લી રહી જાય છે.
વ્યવસ્થિત પ્લેટફોર્મ ટનલમાં કેમ જોડાઈ શકતું નથી
Heroku, AppHarbor કે CloudBees જેવા એપ્લિકેશન પ્લેટફોર્મ તમારો કોડ એવા વાતાવરણમાં ચલાવે છે જ્યાં tun કે tap ઉપકરણ નથી અને એક બનાવવાની સત્તા પણ નથી. તેમનું ઇનબાઉન્ડ મોડેલ HTTP છે, કોઈ મનસ્વી સાંભળતું સોકેટ નહીં. VPN બાઇનરી સાથે લાવતું બિલ્ડપેક પણ ઇન્ટરફેસ મૂકવાની જગ્યા ધરાવતું નથી. કામ કરતી પદ્ધતિઓ છે ડેટાબેઝ મંજૂર કરી શકે એવું સ્થિર આઉટબાઉન્ડ સરનામું, પ્લેટફોર્મ આપે એવું ખાનગી જોડાણ ઉત્પાદન, અથવા DMZ માં HTTPS દ્વારા પહોંચાય એવી પ્રોક્સી.
એ પ્રોક્સી પોતાના પ્રમાણીકરણ અને લોગિંગ સાથેનો ઍક્સેસ માર્ગ છે. તે પ્લેટફોર્મને તમારા VPN નો સભ્ય બનાવતું નથી, અને એમ વર્ણવવાથી એવા નિયમો બને છે જે કોઈ ઓડિટ કરી શકતું નથી.
નિષ્ફળ ગયેલા ક્લાઇન્ટથી ચકાસો
ફરી જોડાઓ અને ક્લાઇન્ટનો ચોક્કસ માર્ગ પુનરાવર્તિત કરો. સેવા જે સ્રોત સરનામું લોગ કરે છે, ડેટાબેઝના નામ માટે ક્લાઇન્ટ જે રૂટ પસંદ કરે છે, અને વાસ્તવિક ક્વેરીનું પરિણામ એ ક્રમમાં ચકાસો. ગેટવેથી કરેલી કસોટી સાબિત કરે છે કે ગેટવે કામ કરે છે, જે ક્યારેય શંકામાં નહોતું. જો જોડાણ હવે પ્રમાણિત થાય અને ક્વેરી હજી નિષ્ફળ જાય, તો બાકીની સમસ્યા ડેટાબેઝની પરવાનગી છે.
ટનલ બદલાય ત્યારે આ નિયમોની સમીક્ષા કરો. બદલાયેલો ગેટવે કે નવી આઉટબાઉન્ડ શ્રેણી એપ્લિકેશન રૂપરેખાંકનમાં કોઈપણ ફેરફાર વિના માર્ગ તોડી નાખે છે.