VPN ગેટવેને Windows XPની બાજુમાં રાખો, અંદર નહીં

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

VPN ક્લાયન્ટથી નહીં, હોસ્ટ એડેપ્ટરથી શરૂ કરો

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

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

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

ટનલને એવા હાર્ડવેર પર મૂકો જેને તમે અપડેટ કરી શકો

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

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

સેવાઓને મંજૂરી આપો, નેટવર્કને નહીં

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

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

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

પુનઃપ્રાપ્તિ ટનલ વિના કામ કરવી જોઈએ

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

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

પ્રમાણપત્રો, ઘડિયાળો અને સહીની ચેતવણીઓ

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

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