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

નિયમ મેળ ખાવાનું કેમ બંધ કરી ગયો

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

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

વિકલ્પ એક: એક સ્થિર સરનામું, ઓછી ગોપનીયતા

સામાન્ય સુધારો હોસ્ટ પર બંને પરિભ્રમણ પ્રક્રિયાઓ બંધ કરે છે: netsh interface ipv6 set privacy state=disabled store=persistent અને netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. જો તમે પુનઃપ્રારંભની રાહ જોયા વિના ફેરફાર અમલમાં આવે તેમ ઇચ્છો તો store=active ઉમેરો, અને સ્વીકારો કે તમે હવે ઓળખકર્તાને નેટવર્ક દરમિયાન અનુમાન કરી શકાય તેવું બનાવ્યું છે.

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

વિકલ્પ બે: પ્રીફિક્સ કે નામને મંજૂરી આપો

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

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

વિકલ્પ ત્રણ: ટનલને સરનામું સોંપવા દો

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

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

ટ્રેકિંગ ખર્ચને ધ્યાનમાં રાખીને પસંદ કરો

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

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

સંબંધિત લેખો