SharePoint లింక్‌లు ప్రచురిత URL కారణంగా VPN-లో విరిగిపోతాయి
VPN ద్వారా లోడ్ అయ్యే SharePoint పేజీ మీ క్లయింట్ పరిష్కరించలేని పేరుపై డాక్యుమెంట్ లింక్‌లను తిరిగి ఇవ్వగలదు. DNS, మార్గం, TLS మరియు ప్రచురిత URL తనిఖీ చేయండి.
VPN ద్వారా SharePoint పేజీ తెరుచుకుంటుంది, మరియు మొదటి డాక్యుమెంట్ లింక్ చిరునామా పట్టీలో ఎప్పుడూ లేని పేరుతో విఫలమవుతుంది. ఆ గ్యాపే మొత్తం సమస్య: పేజీ ఒక 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 గురించి కాదు.