SharePoint estekak VPN bidez hausten dira argitaratutako URLengatik
VPN bidez kargatzen den SharePoint orrialde batek zure bezeroak ezin duen izen batekin itzul ditzake dokumentu estekak. Egiaztatu DNS, ibilbidea, TLS eta argitaratutako URLa.
SharePoint orrialde bat VPN bidez irekitzen da, eta lehen dokumentu-esteka huts egiten du inoiz helbide-barran egon ez zen izen batekin. Hutsune hori da arazo osoa: orrialdea URL batetik etorri zen, eta zerbitzuak hurrengo eskaera beste batetik formateatu zuen. Argitaratutako URLa zerbitzari aldeko erabakia da, beraz bezeroan konpontzea mutur okerra da. Egiaztatu zerbitzuak zein izen itzultzen duen DNS edo ibilbideak ukitu aurretik.
Lehen orrialdeak eta hurrengo eskaerak izen desberdinak erabiltzen dituzte
Helbidearen bidez zerbitzarira iristen den erabiltzaileak funtzionatzen duen hasierako orrialdea ikusten du. Orrialde horretako dokumentu-estekak zerbitzuak argitaratzen duela uste duen URLtik sortzen dira, ez nabigatzaileak idatzi zuenetik. Desberdinak badira, hurrengo klikak bezeroak inoiz ebatzitako ez duen izen batera eramaten du.
Helbidea behin sartzeak ez ditu sortutako esteka guztiak konpontzen, eta helbiderako laster-markak arazoa ezkutatzen du dokumentu bat ireki arte.
Porrot hori erraz irakurtzen da gaizki VPN arazo gisa, tunela erabiltzen hasi ondoren bakarrik agertzen delako. Praktikan tuneak bere lana egiten du: eskaera bide erabilgarririk edo ziurtagiri egokirik ez duen izen batera darama. Bereizi bi galderak bata edo bestea aldatu aurretik. Bata paketea nora doan da, bestea zerbitzuak zein izen argitaratzea aukeratu zuen.
Lau kontrol, izen bat
Argitaratutako izen bakoitzak lau kontrol independente gainditu behar ditu. DNSek benetako bezeroarentzat ebatzi behar du, bideratzeak eta sarbide-politikak bidea baimendu behar dute, TLSek izen horretarako balioztatu behar du, eta zerbitzua hura argitaratzeko konfiguratuta egon behar da.
Kontrol bateko aldaketak ez ditu besteak betetzen. Ziurtagiri-abisua onartzea ez da izen-ebazpenaren konponketa.
Beheko taula egiaztapen-zerrendaren ordena da. Huts egiten duen lehen errenkadan gelditu, geroagoko konponketa batek ezin baitu lehenagoko hutsunerik konpentsatu.
| 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 |
Irakurri argitalpen-eredua aldatu aurretik
SharePoint Server hedapenak desberdinak dira. Web aplikazio klasikoek sarbide-mapa alternatiboak erabil ditzakete, non barne-URLa zerbitzariak jasotzen duena den eta URL publikoa estekak formateatzeko erabiltzen duena. Ostalari-izena duten gune-bildumek beste ikuspegi bat dute eta, Microsoften gidaritzaren arabera, ezin dute AAM erabili.
Microsoften plangintza-gidaritzak AAM funtzioak zaharkitutzat markatzen ditu eta ostalari-izena duten gune-bildumak gomendatzen ditu plangintza bererako. Horrek hedapen-eredua bere jabearen galdera bihurtzen du, ez zuk adabakitzen duzun balio lehenetsia.
Ezarri zein eredu erabiltzen den mapaketa-aldaketa proposatu aurretik. AAM sarrera bat gehitzeak ostalari-izena duen hedapen bati ez du ezer egiten, eta bat gehitzeak hedapen klasiko bati itzulitako esteka guztiak batera aldatzen ditu. Biak konfigurazio-aldaketak dira, eragin zabalekoak, beraz prestatu faseka eta mantendu itzultzeko plan bat. Hau ez da mapa zaharkituak ingurune moderno batean sartzeko gomendioa.
Jarraitu huts egin zuen eragiketari, ez hasierako orrialdeari
Erregistratu huts egin zuen eskaerak benetan erabili zuen helmuga, bezero-aplikazioa, ordua eta errorea. Nabigatzaile batek eta mahaigaineko aplikazio batek proxy, VPN edo autentifikazio bide desberdinak har ditzakete dokumentu berera.
Nabigatzaileak arrakasta izan dezake Office bezeroak huts egiten duen bitartean, eta alde hori zein testuinguruk ebazten duen izenaren arrastoa da.
URLa eta sareko entregatzeak funtzionatzen badute eta zerbitzuak oraindik eragiketa baztertzen badu, gainerako arazoa aplikazio mailakoa da. Dokumentu-baimenak eta ordainketa-egoera zerbitzuaren jabearenak dira, eta VPN ibilbide batek konektibitatea ematen du, ez baimena.
Egiaztatu entrega hasieratik amaierara
Exekutatu egiaztapenak ordenan huts egiten duen bezeroan: ebatzi argitaratutako izena, eskatu orrialdea izen horrekin, gero eskatu dokumentuaren URLa orrialdearen iturburutik. Urrats bakoitzak kontrol bat isolatzen du.
Hiru komandok ebazpena, TLS eta dokumentuaren bidea estaltzen dituzte:
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.aspxEbazpenak tunelean bakarrik huts egiten badu, split-DNS politikak du susmoa. TLSek huts egiten badu, konparatu ziurtagiriaren izena argitaratutako izenarekin, abisua klikatuz pasa beharrean. Biak ondo badoaz eta dokumentuak oraindik huts egiten badu, errorea ez da jada URLari buruzkoa.