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

પાંચ મિનિટની કસોટી જે ફિલ્ટરિંગને બાકીના બધાથી અલગ પાડે છે

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

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

ચાર પરિણામો લગભગ દરેક કિસ્સાને આવરી લે છે. જો 443 કામ કરે છે અને 5432 ફક્ત ટનલ ચાલુ હોય ત્યારે નિષ્ફળ જાય છે, તો તમે એક્ઝિટ પાથ પર પોર્ટ ફિલ્ટરિંગ જોઈ રહ્યા છો. જો ટનલ ચાલુ હોય ત્યારે બંને નિષ્ફળ જાય અને તેના વિના બંને કામ કરે, તો સમસ્યા પોર્ટ નીતિ નહીં, રાઉટિંગ કે DNS છે. જો બંને પોર્ટ કનેક્ટ થાય પણ એપ્લિકેશન હજુ નિષ્ફળ જાય, તો દોષ પહોંચનો નહીં, પ્રમાણીકરણ કે TLSનો છે. અને જો પ્રદાતાનું ફક્ત એક સર્વર સ્થાન નિષ્ફળ જાય, તો તે સર્વર-આધારિત નીતિ છે, તેથી કોઈ પણ ગોઠવણીને સ્પર્શ કરતા પહેલા બીજું સ્થાન અજમાવો.

વિકલ્પ એક: ડેટાબેઝ સબનેટ માટે સ્પ્લિટ ટનલ

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

જે ક્ષણે ડેટાબેઝ તે નેટવર્કની અંદર રહે છે જ્યાં VPN પહોંચવાનું છે, તે કામ કરવાનું બંધ કરે છે, તેથી તેના પર પ્રતિબદ્ધ થવા પહેલા તે ચકાસો.

વિકલ્પ બે: તમારો પોતાનો એન્ડપોઇન્ટ, તમારો પોતાનો એગ્રેસ

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

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

વિકલ્પ ત્રણ: લેપટોપને માર્ગમાંથી બહાર કાઢો

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

તે સ્પ્લિટ-ટનલ નિયમ કરતાં વધુ અગાઉથી કામ માંગે છે, અને જેને અત્યારે જ ઇન્ટરેક્ટિવ સત્રની જરૂર છે તે એક વ્યક્તિને તે મદદ કરતું નથી.

પ્રદાતાનું સરનામું મંજૂર યાદીમાં મૂકવું કેમ ખોટી તુલના છે

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

સમર્પિત અથવા સ્થિર સરનામાં, જ્યાં પ્રદાતા તે વેચે છે, તે આનું એકમાત્ર સ્વરૂપ છે જે સ્કેલ થાય છે. મંજૂર યાદીને ફક્ત તમારા પોતાના સરનામા સાથે બાંધો, અથવા બિલકુલ ન બાંધો.

તમે ગમે તે પસંદ કરો, માર્ગ અને કારણ લખી રાખો. આગલી વ્યક્તિ એ જ રીસેટ થતા કનેક્શનનો સામનો કરશે અને એપ્લિકેશનને દોષ આપવા લાગશે.

સંબંધિત લેખો