રોમિંગ લેપટોપ: સ્થિર નામ કે નિશ્ચિત ઓફિસ સરનામું?

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

ત્રણ જરૂરિયાતોને અલગ કરો

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

મોટાભાગની રોમિંગ ફરિયાદો પહેલા ટોપલામાં પડે છે અને DNS માં ઠીક થાય છે. સ્થિર ઓળખનું નામકરણ સસ્તું છે અને પહેલો કિસ્સો આવરી લે છે. સરનામું જાળવવું ખર્ચાળ છે અને બીજાને ત્યારે જ મદદ કરે છે જ્યારે નીતિ કોઈપણ રીતે ફરી લખવાની હોય.

નામને સ્થિર વસ્તુ બનાવો

લેપટોપને એવું નામ આપો જે કૉલર સુધી પહોંચી શકે તેવા કોઈપણ સરનામા પર ઉકેલાય. આ ઉદાહરણમાં ઓફિસનું સરનામું 192.168.50.42 છે, રિમોટ-એક્સેસ પૂલ 10.90.0.42 આપે છે, અને laptop17.corp.example જોડાણને અનુસરે છે. કોઈ પણ વસ્તુ છેલ્લા ઓક્ટેટને મેળ ખાવાની જરૂર માંગતી નથી, અને એ મેળની આસપાસ રચના કરવાથી કોઈ લાભ વિના કામ ઊભું થાય છે. રેકોર્ડ એ સરનામા તરફ ઈશારો કરવો જોઈએ જે કૉલર ખરેખર વાપરી શકે, લેપટોપ પાસે અત્યાર સુધી હતા તે દરેક ઇન્ટરફેસ તરફ નહીં.

dig +short laptop17.corp.example

રિઝોલ્વર્સ જવાબો કૅશ કરે છે, તેથી ફેરફાર બધા માટે તાત્કાલિક નથી. ટૂંકા TTL મદદ કરે છે, અને એપ્લિકેશનનું પુનઃજોડાણ તર્ક વધુ મદદ કરે છે.

જ્યારે સ્રોત મંજૂરી-યાદી જ ખરી મર્યાદા હોય

સ્રોત મંજૂરી-યાદી સંરક્ષિત સેવાને મળતું સરનામું જુએ છે, કોઈપણ અનુવાદ પછી. તે ઘણી વાર ગેટવે કે NAT સરનામું હોય છે, લેપટોપનું પોતાનું નહીં, તેથી DNS રેકોર્ડ સંપાદિત કરવાથી નકારાયેલી વિનંતી ક્યારેય સુધરતી નથી. જે સરનામું ખરેખર આવે છે તેના માટે નીતિ અપડેટ કરો, અથવા યાદીને પ્રમાણિત ઓળખ સાથે બદલો.

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

સાતત્યતા ખરેખર શું માંગે છે

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

ss -tnp state established '( dport = :443 )'

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