મેઇલ VPN વિના સર્વર સુધી પહોંચે છે: નિયમ ક્યાં લાગુ કરવો

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

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

લક્ષણ Mac જેવું લાગે છે, પણ લીક સર્વર હોઈ શકે

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

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

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

સર્વર પ્રવેશ: એપ નહીં, સ્રોત નકારો

હોસ્ટ અથવા નેટવર્ક ફાયરવોલ મેઇલ શ્રોતાને મંજૂર સ્રોત શ્રેણી સુધી મર્યાદિત કરી શકે છે અને પ્રમાણીકરણ તથા TLS અપરિવર્તિત રાખી શકે છે. દૂરના સરનામા, સબનેટ અથવા શ્રેણી સાથે મેળ ખાતી નિયમ-શરત સામાન્ય બાંધકામ-બ્લોક છે; ચોક્કસ સિન્ટેક્સ સર્વરના ફાયરવોલ ઉત્પાદનનું છે, મેઇલ એપનું નહીં.

જ્યારે જરૂરિયાત «સેવાએ સીધા ક્લાયન્ટની સેવા ન કરવી જોઈએ» હોય ત્યારે આ સૌથી મજબૂત સીમા છે. વપરાશકર્તા બીજું મેઇલ ક્લાયન્ટ સ્થાપિત કરે તોપણ તે ટકે છે, કારણ કે નકાર પ્રમાણીકરણ પહેલાં થાય છે. તે Mac ને પણ ટકી રહે છે જે પોતાની VPN નીતિને અવગણે છે.

તેની મર્યાદા પણ એટલી જ મહત્ત્વની છે. નકારાયેલું કનેક્શન સાબિત કરે છે કે સેવાએ સત્ર નકાર્યું; તે સાબિત કરતું નથી કે Mac એ કોઈ પ્રયાસ કર્યો નથી. DNS રિઝોલ્યુશન, અગાઉના લોડ બેલેન્સર તરફ TCP SYN અને નિષ્ફળતા પછી ફરી પ્રયાસ — બધું સર્વરના નિયમ સુધી પહોંચતાં પહેલાં થઈ શકે છે. જો જરૂરિયાત પ્રવેશને બદલે પ્રયાસોના જાહેર થવા વિશે હોય, તો સર્વર પ્રવેશ નિયંત્રણનો અડધો ભાગ છે.

ક્લાયન્ટ પર અમલ: ફક્ત ટનલ નહીં, પ્રયાસ અવરોધો

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

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

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

એપ-સ્તર અને ગંતવ્ય-સ્તરના નિયમોનો અસરવ્યાપ જુદો છે

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

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

જરૂરિયાતના શબ્દો પ્રમાણે પસંદ કરો. «આ કામનું એકાઉન્ટ સીધું જોડાઈ ન શકે» ગંતવ્ય વ્યાપ તરફ ઇશારો કરે છે. «આ Mac એ VPNની બહાર મેઇલ ચલાવવો ન જોઈએ» વિશાળ એપ-નિયમને ન્યાયી ઠેરવે છે, જો માલિક અંગત એકાઉન્ટની આડઅસર સ્વીકારે.

નકાર અને ગેરહાજરી અલગ અલગ ચકાસો

સમર્પિત કસોટી એકાઉન્ટ સાથે VPN દ્વારા જોડાઓ અને સામાન્ય કાર્ય પુષ્ટ કરો. પછી ડિસ્કનેક્ટ કરો અને બે વાર ચકાસો: એક વાર એ જોવા માટે કે સર્વર લોગિન નકારે છે કે નહીં, અને એક વાર એ જોવા માટે કે Mac જરાય કનેક્શનનો પ્રયાસ કરે છે કે નહીં. એ અલગ અવલોકનો છે અને તે અલગ લોગમાં જાય છે.

ડિસ્કનેક્ટ હોય ત્યારે SYN કે DNS પ્રશ્ન માટે ક્લાયન્ટ બાજુના પુરાવા જુઓ, અને નકારાયેલ કે સ્વીકારાયેલ સત્ર માટે સર્વરનો લોગ જુઓ. જો સર્વર નકારે પણ ક્લાયન્ટ તોપણ પ્રયાસ કરે, તો સર્વરનો નિયમ કામ કરે છે અને ક્લાયન્ટનો નિયમ ગેરહાજર છે. જો ક્લાયન્ટ કોઈ પ્રયાસ ન કરે પણ સર્વર હજી બીજા ક્લાયન્ટ સ્વીકારે, તો સીમા બરાબર ત્યાં જ છે જ્યાં તમે તેને મૂકી હતી.

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