SharePoint-ligiloj rompiĝas tra VPN pro publikigitaj URL-oj
Paĝo de SharePoint ŝargita tra VPN ankoraŭ povas redoni dokumentajn ligilojn per nomo, kiun via kliento ne povas solvi. Kontrolu DNS, itineron, TLS kaj la publikigitan URL-on.
Paĝo de SharePoint malfermiĝas tra la VPN, kaj la unua dokumenta ligilo fiaskas per nomo, kiu neniam estis en la adresbreto. Tiu breĉo estas la tuta problemo: la paĝo venis de unu URL, kaj la servo formatis la sekvan peton el alia. La publikigita URL estas decido ĉe la servila flanko, do ripari ĝin ĉe la kliento estas la malĝusta fino. Kontrolu, kiun nomon la servo redonas, antaŭ ol tuŝi DNS aŭ itinerojn.
La unua paĝo kaj la sekva peto uzas malsamajn nomojn
Uzanto, kiu atingas la servilon per la adreso, vidas funkciantan ĉefpaĝon. La dokumentaj ligiloj sur tiu paĝo estas generataj el la URL, kiun la servo kredas publikigi, ne el tio, kion la retumilo tajpis. Se ili malsamas, la sekva alklako iras al nomo, kiun la kliento neniam solvis.
Enigi la adreson unufoje ne riparas ĉiun generitan ligilon, kaj legosigno al la adreso kaŝas la problemon ĝis dokumento malfermiĝas.
Ĉi tiu fiasko facile mislegiĝas kiel VPN-problemo, ĉar ĝi aperas nur post kiam la tunelo estas uzata. Fakte la tunelo faras sian laboron: ĝi portas la peton al nomo sen funkcianta vojo aŭ sen kongrua atestilo. Apartigu la du demandojn antaŭ ol ŝanĝi iun ajn. Unu estas kien la pako iras, la alia estas kiun nomon la servo elektis publikigi.
Kvar kontroloj, unu nomo
Ĉiu publikigita nomo devas trapasi kvar sendependajn kontrolojn. DNS devas solvi ĝin por la reala kliento, enkursigado kaj alirpolitiko devas permesi la vojon, TLS devas validigi tiun nomon, kaj la servo devas esti agordita por publikigi ĝin.
Ŝanĝo en unu kontrolo ne plenumas la aliajn. Akcepti atestilan averton ne estas riparo de nomsolvado.
La suba tabelo estas la ordo de la kontrol-listo. Haltu ĉe la unua vico, kiu fiaskas, ĉar posta ripeto ne povas kompensi pli fruan breĉon.
| 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 |
Legu la publikigan modelon antaŭ ol ŝanĝi ĝin
SharePoint Server-evoluigoj malsamas. Klasikaj retaplikaĵoj povas uzi alternajn alirmapojn, kie interna URL estas tio, kion la servilo ricevas, kaj publika URL estas tio, kion ĝi uzas por formati ligilojn. Gastnomaj retejaj kolektoj sekvas alian aliron kaj, laŭ la gvidado de Microsoft, ne povas uzi AAM.
La planada gvidado de Microsoft ankaŭ markas AAM-funkciojn kiel eksdataj kaj rekomendas gastnomajn retejajn kolektojn por nova planado. Tio faras la evoluigan modelon demando por ĝia posedanto, ne defaŭlto, kiun vi flikas.
Determinu, kiu modelo estas uzata, antaŭ ol proponi ŝanĝon de mapado. Aldoni AAM-eron al gastnoma evoluigo faras nenion, kaj aldoni unu al klasika evoluigo ŝanĝas ĉiun redonitan ligilon samtempe. Ambaŭ estas agordaj ŝanĝoj kun granda efiko, do preparu ilin laŭetape kaj tenu revojan planon. Ĉi tio ne estas rekomendo enkonduki malnovajn mapojn en modernan medion.
Sekvu la fiaskintan operacion, ne la ĉefpaĝon
Notu la celon, kiun la fiaskinta peto efektive uzis, la klientan aplikaĵon, la tempon kaj la eraron. Retumilo kaj surtabla aplikaĵo povas preni malsamajn prokurajn, VPN-ajn aŭ aŭtentigajn vojojn al la sama dokumento.
La retumilo povas sukcesi dum la Office-kliento fiaskas, kaj tiu diferenco estas signo pri tio, kiu kunteksto solvas la nomon.
Se la URL kaj la reta transdono ambaŭ funkcias kaj la servo ankoraŭ malakceptas la operacion, la restanta problemo estas ĉe aplikaĵa nivelo. Dokumentaj permesoj kaj elŝuta stato apartenas al la serva posedanto, kaj VPN-itinero liveras konektecon, ne permeson.
Kontrolu la transdonon de fino al fino
Rulu la kontrolojn en ordo ĉe la fiaskanta kliento: solvu la publikigitan nomon, petu la paĝon per tiu nomo, poste petu la dokumentan URL el la fonto de la paĝo. Ĉiu paŝo izolas unu kontrolon.
Tri komandoj kovras solvadon, TLS kaj la dokumentan vojon:
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.aspxSe solvado fiaskas nur tra la tunelo, la split-DNS-politiko estas la suspektato. Se TLS fiaskas, komparu la atestilan nomon kun la publikigita nomo anstataŭ alklaki tra la averto. Se ambaŭ sukcesas kaj la dokumento ankoraŭ fiaskas, la eraro jam ne plu temas pri la URL.