SharePoint લિંક્સ પ્રકાશિત URLને કારણે VPN પર તૂટી જાય છે
VPN પર લોડ થતું SharePoint પૃષ્ઠ હજી પણ એવા નામ પર દસ્તાવેજ લિંક્સ પરત આપી શકે છે જે તમારો ક્લાયન્ટ ઉકેલી શકતો નથી. DNS, રૂટ, TLS અને પ્રકાશિત URL તપાસો.
VPN દ્વારા SharePoint પૃષ્ઠ ખૂલે છે, અને પ્રથમ દસ્તાવેજ લિંક એવા નામ સાથે નિષ્ફળ જાય છે જે ક્યારેય સરનામાં બારમાં નહોતું. આ ગેપ એ જ આખી સમસ્યા છે: પૃષ્ઠ એક URL પરથી આવ્યું, અને સેવાએ આગળની વિનંતી બીજા URL પરથી ફોર્મેટ કરી. પ્રકાશિત URL સર્વર-બાજુનો નિર્ણય છે, તેથી તેને ક્લાયન્ટ પર સુધારવું ખોટો અંત છે. DNS કે રૂટને સ્પર્શ કરતા પહેલાં સેવા કયું નામ પરત આપે છે તે તપાસો.
પ્રથમ પૃષ્ઠ અને આગળની વિનંતી જુદાં નામો વાપરે છે
સરનામા દ્વારા સર્વર પર પહોંચતો વપરાશકર્તા કાર્યરત હોમપેજ જુએ છે. તે પૃષ્ઠની દસ્તાવેજ લિંક્સ એ URL પરથી બને છે જે સેવા પ્રકાશિત કરે છે એમ માને છે, બ્રાઉઝરે ટાઇપ કર્યું તેના પરથી નહીં. જો તે જુદી હોય, તો આગળનું ક્લિક એવા નામ પર જાય છે જે ક્લાયન્ટે ક્યારેય ઉકેલ્યું નથી.
સરનામું એક વાર દાખલ કરવાથી દરેક જનરેટ થયેલી લિંક સુધરતી નથી, અને સરનામાનું બુકમાર્ક દસ્તાવેજ ખૂલે ત્યાં સુધી સમસ્યા છુપાવે છે.
આ નિષ્ફળતાને VPN સમસ્યા તરીકે ખોટી રીતે વાંચવી સરળ છે, કારણ કે તે ટનલ વપરાયા પછી જ દેખાય છે. વાસ્તવમાં ટનલ પોતાનું કામ કરે છે: તે વિનંતીને એવા નામ પર લઈ જાય છે જેનો કાર્યરત માર્ગ કે મેળ ખાતું પ્રમાણપત્ર નથી. બંનેમાંથી કોઈપણ બદલતા પહેલાં બે પ્રશ્નો અલગ કરો. એક છે પેકેટ ક્યાં જાય છે, બીજો છે સેવાએ પ્રકાશિત કરવા કયું નામ પસંદ કર્યું.
ચાર નિયંત્રણો, એક નામ
દરેક પ્રકાશિત નામે ચાર સ્વતંત્ર નિયંત્રણો પસાર કરવા પડે. DNS એ તેને વાસ્તવિક ક્લાયન્ટ માટે ઉકેલવું પડે, રૂટિંગ અને ઍક્સેસ નીતિએ માર્ગની પરવાનગી આપવી પડે, TLS એ તે નામ માટે માન્યતા આપવી પડે, અને સેવા તેને પ્રકાશિત કરવા કન્ફિગર થયેલી હોવી પડે.
એક નિયંત્રણમાં ફેરફાર બાકીનાને પૂર્ણ કરતો નથી. પ્રમાણપત્ર ચેતવણી સ્વીકારવી એ નામ-ઉકેલનું સમારકામ નથી.
નીચેનું કોષ્ટક ચેકલિસ્ટનો ક્રમ છે. જે પ્રથમ પંક્તિ નિષ્ફળ જાય ત્યાં થોભો, કારણ કે પછીનું સુધારણું અગાઉના ગેપની ભરપાઈ કરી શકતું નથી.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
બદલતા પહેલાં પ્રકાશન મોડેલ વાંચો
SharePoint Server જમાવટો અલગ હોય છે. ક્લાસિક વેબ એપ્લિકેશનો વૈકલ્પિક ઍક્સેસ મેપિંગ વાપરી શકે છે, જ્યાં આંતરિક URL એ છે જે સર્વર મેળવે છે અને જાહેર URL એ છે જે લિંક્સ ફોર્મેટ કરવા માટે વાપરે છે. હોસ્ટ-નામવાળા સાઇટ સંગ્રહો અલગ અભિગમ અનુસરે છે અને Microsoftની માર્ગદર્શિકા મુજબ AAM વાપરી શકતા નથી.
Microsoftની આયોજન માર્ગદર્શિકા AAM સુવિધાઓને અપ્રચલિત તરીકે ચિહ્નિત કરે છે અને નવા આયોજન માટે હોસ્ટ-નામવાળા સાઇટ સંગ્રહોની ભલામણ કરે છે. તે જમાવટ મોડેલને તેના માલિકનો પ્રશ્ન બનાવે છે, તમે પેચ કરો તેવું ડિફોલ્ટ નહીં.
મેપિંગ ફેરફાર સૂચવતા પહેલાં કયું મોડેલ વપરાય છે તે નક્કી કરો. હોસ્ટ-નામવાળી જમાવટમાં AAM એન્ટ્રી ઉમેરવાથી કંઈ થતું નથી, અને ક્લાસિક જમાવટમાં એક ઉમેરવાથી દરેક પરત આપેલી લિંક એકસાથે બદલાય છે. બંને વ્યાપક અસરવાળા કન્ફિગરેશન ફેરફારો છે, તેથી તેમને તબક્કાવાર તૈયાર કરો અને રોલબેક રાખો. આ આધુનિક વાતાવરણમાં જૂની મેપિંગ લાવવાની ભલામણ નથી.
નિષ્ફળ કામગીરીને અનુસરો, હોમપેજને નહીં
નિષ્ફળ વિનંતીએ વાસ્તવમાં વાપરેલું લક્ષ્ય, ક્લાયન્ટ એપ્લિકેશન, સમય અને ભૂલ નોંધો. બ્રાઉઝર અને ડેસ્કટોપ એપ્લિકેશન એક જ દસ્તાવેજ સુધી અલગ પ્રોક્સી, VPN કે પ્રમાણીકરણ માર્ગ લઈ શકે છે.
બ્રાઉઝર સફળ થઈ શકે છે જ્યારે Office ક્લાયન્ટ નિષ્ફળ જાય, અને તે તફાવત એ સંકેત છે કે કયો સંદર્ભ નામ ઉકેલે છે.
જો URL અને નેટવર્ક હેન્ડઑફ બંને કામ કરે અને સેવા હજી પણ કામગીરી નકારે, તો બાકીની સમસ્યા એપ્લિકેશન સ્તરની છે. દસ્તાવેજ પરવાનગીઓ અને ચેક-આઉટ સ્થિતિ સેવાના માલિકની છે, અને VPN રૂટ કનેક્ટિવિટી આપે છે, પરવાનગી નહીં.
હેન્ડઑફ શરૂઆતથી અંત સુધી તપાસો
નિષ્ફળ જતા ક્લાયન્ટ પર ક્રમમાં તપાસ ચલાવો: પ્રકાશિત નામ ઉકેલો, તે નામ સાથે પૃષ્ઠ માંગો, પછી પૃષ્ઠ સ્રોતમાંથી દસ્તાવેજનું URL માંગો. દરેક પગલું એક નિયંત્રણ અલગ કરે છે.
ત્રણ આદેશો ઉકેલ, TLS અને દસ્તાવેજ માર્ગ આવરી લે છે:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspxજો ઉકેલ ફક્ત ટનલ દ્વારા નિષ્ફળ જાય, તો split-DNS નીતિ શંકાસ્પદ છે. જો TLS નિષ્ફળ જાય, તો પ્રમાણપત્રનું નામ પ્રકાશિત નામ સાથે સરખાવો, ક્લિક કરીને આગળ વધવાને બદલે. જો બંને સફળ થાય અને દસ્તાવેજ હજી નિષ્ફળ જાય, તો ભૂલ હવે URL વિશે નથી.