SharePoint saitai lūžta per VPN dėl paskelbtų URL
SharePoint puslapis, įkeliamas per VPN, vis tiek gali grąžinti dokumentų nuorodas vardu, kurio jūsų klientas negali išspręsti. Patikrinkite DNS, maršrutą, TLS ir paskelbtą URL.
SharePoint puslapis atsidaro per VPN, ir pirmoji dokumento nuoroda nepavyksta su vardu, kurio niekada nebuvo adreso juostoje. Šis atotrūkis yra visa problema: puslapis atėjo iš vieno URL, o paslauga suformavo kitą užklausą iš kito. Paskelbtas URL yra serverio pusės sprendimas, todėl taisyti jį kliente yra netinkamas galas. Patikrinkite, kokį vardą grąžina paslauga, prieš liesdami DNS ar maršrutus.
Pirmasis puslapis ir kita užklausa naudoja skirtingus vardus
Vartotojas, pasiekiantis serverį adresu, mato veikiantį pagrindinį puslapį. To puslapio dokumentų nuorodos generuojamos iš URL, kurį paslauga mano skelbianti, o ne iš to, ką įvedė naršyklė. Jei jie skiriasi, kitas spustelėjimas eina į vardą, kurio klientas niekada neišsprendė.
Adreso įvedimas vieną kartą nesutaiso kiekvienos sugeneruotos nuorodos, o adreso žymė slepia problemą, kol dokumentas neatidaromas.
Šią nesėkmę lengva neteisingai perskaityti kaip VPN problemą, nes ji pasirodo tik pradėjus naudoti tunelį. Iš tikrųjų tunelis atlieka savo darbą: jis neša užklausą į vardą, kuris neturi veikiančio kelio ar atitinkančio sertifikato. Atskirkite abu klausimus, prieš keisdami bet kurį. Vienas yra kur paketas eina, kitas yra kokį vardą paslauga pasirinko skelbti.
Keturi valdikliai, vienas vardas
Kiekvienas paskelbtas vardas turi praeiti keturis nepriklausomus valdiklius. DNS turi jį išspręsti faktiniam klientui, maršrutizavimas ir prieigos politika turi leisti kelią, TLS turi patvirtinti tą vardą, o paslauga turi būti sukonfigūruota jį skelbti.
Vieno valdiklio pakeitimas neatlieka kitų. Sertifikato įspėjimo priėmimas nėra vardo sprendimo taisymas.
Lentelė žemiau yra kontrolinio sąrašo tvarka. Sustokite pirmoje eilutėje, kuri nepavyksta, nes vėlesnis taisymas negali kompensuoti ankstesnės spragos.
| 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 |
Perskaitykite skelbimo modelį prieš jį keisdami
SharePoint Server diegimai skiriasi. Klasikinės žiniatinklio programos gali naudoti alternatyvius prieigos susiejimus, kur vidinis URL yra tai, ką gauna serveris, o viešasis URL yra tai, ką jis naudoja nuorodoms formatuoti. Pagrindinio kompiuterio vardo svetainių rinkiniai laikosi kitokio požiūrio ir, pagal Microsoft gaires, negali naudoti AAM.
Microsoft planavimo gairės taip pat žymi AAM funkcijas kaip pasenusias ir naujam planavimui rekomenduoja pagrindinio kompiuterio vardo svetainių rinkinius. Tai daro diegimo modelį jo savininko klausimu, o ne numatytąja verte, kurią jūs lopote.
Nustatykite, kuris modelis naudojamas, prieš siūlydami susiejimo pakeitimą. AAM įrašo įtraukimas į pagrindinio kompiuterio vardo diegimą nieko nedaro, o vieno įtraukimas į klasikinį diegimą pakeičia visas grąžinamas nuorodas vienu metu. Abu yra konfigūracijos pakeitimai su plačiu poveikiu, todėl paruoškite juos etapais ir laikykite atšaukimo planą. Tai nėra rekomendacija įvesti senus susiejimus į modernią aplinką.
Sekite nepavykusią operaciją, o ne pagrindinį puslapį
Užrašykite tikslą, kurį nepavykusi užklausa faktiškai naudojo, kliento programą, laiką ir klaidą. Naršyklė ir darbalaukio programa gali eiti skirtingais tarpinio serverio, VPN ar autentifikavimo keliais iki to paties dokumento.
Naršyklė gali pavykti, o Office klientas nepavykti, ir šis skirtumas yra užuomina, kuri aplinka išsprendžia vardą.
Jei URL ir tinklo perdavimas abu veikia, o paslauga vis tiek atmeta operaciją, likusi problema yra programos lygmenyje. Dokumentų leidimai ir mokėjimo būsena priklauso paslaugos savininkui, o VPN maršrutas suteikia ryšį, o ne leidimą.
Patikrinkite perdavimą nuo pradžios iki pabaigos
Vykdykite patikras iš eilės kliente, kuris nepavyksta: išspręskite paskelbtą vardą, paprašykite puslapio tuo vardu, tada paprašykite dokumento URL iš puslapio šaltinio. Kiekvienas žingsnis izoliuoja vieną valdiklį.
Trys komandos apima sprendimą, TLS ir dokumento kelią:
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.aspxJei sprendimas nepavyksta tik per tunelį, įtariamasis yra split-DNS politika. Jei TLS nepavyksta, palyginkite sertifikato vardą su paskelbtu vardu, o ne spustelėkite pro įspėjimą. Jei abu pavyksta, o dokumentas vis tiek nepavyksta, klaida nebėra apie URL.