સાઇટ VPN પર મેપ કરેલી ડ્રાઇવ: DNS, SMB અને UNC પાથ
નેટવર્ક શોધ રાઉટેડ લિંક પાર કરતી નથી, પણ નામવાળો UNC પાથ કરે છે. DNS ને સર્વર તરફ દિશામાન કરો, SMB બંને દિશામાં ખોલો અને પછી ડ્રાઇવ મેપ કરો.
Explorer માં નેટવર્ક પેજ એ ઉપકરણો બતાવે છે જેમણે સ્થાનિક સેગમેન્ટમાં પોતાની જાહેરાત કરી છે, અને રાઉટેડ ટનલ એ જાહેરાતોમાંથી એક પણ લઈ જતી નથી. તેથી સર્વર સંપૂર્ણ પહોંચમાં હોઈ શકે જ્યારે વપરાશકર્તા સામેની વિન્ડો ખાલી રહે. નામવાળો UNC પાથ શોધ પર બિલકુલ આધારિત નથી, અને ઉકેલ એ છે કે નામ ઉકેલાય અને પોર્ટ જવાબ આપે. ખાલી વિન્ડો ખોટા સ્તરની નિશાની છે, બગડેલા શેરની નહીં.
શોધ અને પહોંચ એક જ વસ્તુ નથી
Windows નજીકની મશીનો બ્રોડકાસ્ટ ડોમેન માટે બનેલા પ્રોટોકોલથી શોધે છે અને પછી જે મળ્યું તે સુવિધાની યાદી તરીકે બતાવે છે. તે યાદીમાંથી કંઈ પણ SMB ફાઇલ પ્રવેશ માટે જરૂરી નથી. જે ક્લાઇન્ટ સર્વરનું નામ જાણે છે અને TCP 445 સુધી પહોંચે છે, તે શેર ખોલશે, મશીન કદી નેટવર્કમાં દેખાય કે ન દેખાય.
બંને સ્તરો અલગ અલગ નિષ્ફળ જાય છે, તેથી "મને તે દેખાતું નથી" અને "હું તે ખોલી શકતો નથી" અલગ ચકાસણીને લાયક છે. યાદી જોવી શોધ વિશે કહે છે; પાથ ખોલવો સેવા વિશે કહે છે.
શેર મેપ કરતાં પહેલાં સર્વરને નામ આપો
ફાઇલ સર્વરને DNS માં તેની સામેની બાજુના સરનામા સાથે પ્રકાશિત કરો અને ક્લાઇન્ટ સાઇટને એવા resolver તરફ દિશામાન કરો જે તે ઝોન માટે જવાબ આપી શકે. સંપૂર્ણ લાયક નામ સ્થાનિક પ્રત્યય શોધ યાદી પરની અવલંબન ટાળે છે, જે સામાન્ય રીતે ટૂંકું નામ એક સાઇટ પર ચાલે અને બીજી પર નિષ્ફળ જાય તેનું કારણ છે.
જો પર્યાવરણ Active Directory વાપરે છે, તો નામ ઉકેલવું પ્રમાણીકરણનો પણ ભાગ છે: ક્લાઇન્ટને Kerberos માટે ડોમેન કંટ્રોલર સુધી પહોંચવું પડે છે, અને ખૂબ અસંગત ઘડિયાળ ટિકિટની આપલે નિષ્ફળ કરશે. આ SMB પહોંચ કરતાં જુદી સમસ્યા છે અને ઓળખપત્રની ભૂલ જેવી લાગે છે. પાસવર્ડ ફરી લખતાં પહેલાં ડોમેન કંટ્રોલર ચકાસો.
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
બંને દિશામાં રાઉટિંગ અને ફિલ્ટરિંગ
સાઇટ-થી-સાઇટ ટનલને સ્થાનિક રાઉટ કોષ્ટકમાં દૂરનો પ્રીફિક્સ અને દૂરના કોષ્ટકમાં સ્થાનિક પ્રીફિક્સ જોઈએ, અને દરેક બાજુના ફાયરવોલે આવતા ટ્રાફિકને મંજૂરી આપવી જોઈએ. એકતરફી રૂપરેખા એવું જોડાણ બનાવે છે જે ખૂલે છે અને કદી જવાબ આપતું નથી, જેને વપરાશકર્તાઓ શેર ધીમું હોવાનું કહે છે. પહેલાં ટનલના પોતાના કાઉન્ટર તપાસો. પેકેટ બહાર જાય અને કંઈ પાછું ન આવે તો પરત માર્ગ કે દૂરનું ફિલ્ટર જુઓ.
WireGuard માં પીઅરના મંજૂર IP અને ઓપરેટિંગ સિસ્ટમના રૂટ તે ડિઝાઇન સાથે મેળ ખાવા જોઈએ. ટનલ પેકેટ વહન કરે છે; તે DNS રેકોર્ડ કે શેર પરવાનગીઓ પ્રદાન કરતી નથી કોઈ પણ બાજુએ.
ફાયરવોલ નિયમ ખરેખર જોડાવાના સ્રોત નેટવર્ક પર આધારિત રાખો અને અપવાદ લખી રાખો. જો ડિઝાઇન માર્ગમાં ક્યાંય સરનામાં અનુવાદિત કરે, તો નિયમે અનુવાદિત સ્રોત વાપરવો જોઈએ, અને મૂળ ક્લાઇન્ટ સરનામું હવે લોગમાં દેખાતું નથી.
પ્રમાણીકરણ કરો, પછી ડ્રાઇવ મેપ કરો
Explorer વિન્ડોને બદલે આદેશોથી સ્તરો પાર કરો:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noબીજો આદેશ TCP પાથ સાબિત કરે છે, કંઈ વાંચવાનો હક નહીં. ત્રીજો એ જગ્યા છે જ્યાં પ્રમાણીકરણ અને અધિકૃતિ લાગુ પડે છે, અને ત્યાંની નિષ્ફળતા તમને રાઉટર તરફ નહીં પણ શેર અને ફાઇલ સિસ્ટમની પરવાનગીઓ તરફ મોકલવી જોઈએ.
SMB સહી અને હાલની પ્રમાણીકરણ નીતિ અકબંધ રાખો. સ્પષ્ટ પાથ માટે SMB1 ફરી સક્રિય કરવું કે શોધ બ્રોડકાસ્ટ ટનલમાંથી મોકલવું જરૂરી નથી, અને TCP 445 ખાનગી પાથ પર જ રહેવું જોઈએ, ઇન્ટરનેટ તરફના ફોરવર્ડ પર નહીં. વપરાશકર્તાઓને મંજૂર નામ પર વ્યવસ્થિત શોર્ટકટ કે મેપ કરેલી ડ્રાઇવ આપો, અને ખાલી નેટવર્ક પેજ હવે મહત્ત્વનું રહેશે નહીં.