SharePointi lingid katkevad VPN-is avaldatud URL-ide tõttu
VPN-i kaudu laaditud SharePointi leht võib siiski tagastada dokumendilinke nimega, mida teie klient ei suuda lahendada. Kontrollige DNS-i, marsruuti, TLS-i ja avaldatud URL-i.
SharePointi leht avaneb VPN-i kaudu ja esimene dokumendilink ebaõnnestub nimega, mida aadressiribale kunagi ei olnud. See lünk on kogu probleem: leht tuli ühelt URL-ilt ja teenus vormindas järgmise päringu teiselt. Avaldatud URL on serveripoolne otsus, seega selle kliendis parandamine on vale ots. Kontrollige, millise nime teenus tagastab, enne kui puudutate DNS-i või marsruute.
Esimene leht ja järgmine päring kasutavad erinevaid nimesid
Kasutaja, kes jõuab serverini aadressi kaudu, näeb töötavat avalehte. Selle lehe dokumendilingid genereeritakse URL-ilt, mille teenus arvab end avaldavat, mitte sellest, mille brauser sisestas. Kui need erinevad, läheb järgmine klõps nimele, mida klient pole kunagi lahendanud.
Aadressi ühekordne sisestamine ei paranda kõiki genereeritud linke ja aadressile pandud järjehoidja varjab probleemi, kuni dokument avatakse.
Seda tõrget on lihtne valesti lugeda VPN-i probleemiks, sest see ilmneb alles siis, kui tunnel on kasutusel. Tegelikult teeb tunnel oma tööd: see viib päringu nimele, millel pole töötavat teed ega sobivat sertifikaati. Eraldage kaks küsimust enne, kui kumbagi muudate. Üks on see, kuhu pakett läheb, teine see, millise nime teenus avaldada valis.
Neli kontrolli, üks nimi
Iga avaldatud nimi peab läbima neli sõltumatut kontrolli. DNS peab selle tegeliku kliendi jaoks lahendama, marsruutimine ja juurdepääsupoliitika peavad tee lubama, TLS peab selle nime valideerima ja teenus peab olema seadistatud seda avaldama.
Muudatus ühes kontrollis ei täida teisi. Sertifikaadihoiatuse aktsepteerimine ei ole nime lahendamise parandus.
Allolev tabel on kontroll-loendi järjekord. Peatuge esimesel real, mis ebaõnnestub, sest hilisem parandus ei saa varasemat lünka korvata.
| 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 |
Lugege avaldamismudelit enne selle muutmist
SharePoint Serveri juurutused erinevad. Klassikalised veebirakendused võivad kasutada alternatiivseid juurdepääsu vastendusi, kus sisemine URL on see, mida server vastu võtab, ja avalik URL see, mida ta linkide vormindamiseks kasutab. Hostinimega saidikogud järgivad teistsugust lähenemist ja Microsofti juhiste kohaselt ei saa need AAM-i kasutada.
Microsofti planeerimisjuhised märgivad ka AAM-i funktsioonid vananenuks ja soovitavad uue planeerimise jaoks hostinimega saidikogusid. See teeb juurutusmudeli selle omaniku küsimuseks, mitte vaikeväärtuseks, mida te lappite.
Tehke kindlaks, millist mudelit kasutatakse, enne kui pakute vastenduse muutmist. AAM-kirje lisamine hostinimega juurutusele ei tee midagi ja ühe lisamine klassikalisele juurutusele muudab kõik tagastatud lingid korraga. Mõlemad on suure mõjuga seadistusmuudatused, seega valmistage need etappide kaupa ette ja hoidke tagasipööramise plaan. See ei ole soovitus tuua vanu vastendusi kaasaegsesse keskkonda.
Jälgige ebaõnnestunud toimingut, mitte avalehte
Kirjutage üles sihtkoht, mida ebaõnnestunud päring tegelikult kasutas, kliendirakendus, aeg ja viga. Brauser ja töölauarakendus võivad sama dokumendini jõuda erinevaid puhverserveri, VPN-i või autentimise teid pidi.
Brauser võib õnnestuda, samal ajal kui Office'i klient ebaõnnestub, ja see erinevus on vihje, milline kontekst nime lahendab.
Kui URL ja võrguüleandmine mõlemad töötavad ning teenus lükkab toimingu endiselt tagasi, on ülejäänud probleem rakenduse tasandil. Dokumendi load ja väljaregistreerimise olek kuuluvad teenuse omanikule ning VPN-i marsruut annab ühenduvuse, mitte loa.
Kontrollige üleandmist algusest lõpuni
Käivitage kontrollid järjekorras kliendis, mis ebaõnnestub: lahendage avaldatud nimi, küsige lehte selle nimega, seejärel küsige dokumendi URL-i lehe lähtekoodist. Iga samm isoleerib ühe kontrolli.
Kolm käsku katavad lahendamise, TLS-i ja dokumendi tee:
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.aspxKui lahendamine ebaõnnestub ainult tunnelit pidi, on kahtlusalune split-DNS-i poliitika. Kui TLS ebaõnnestub, võrrelge sertifikaadi nime avaldatud nimega, selle asemel et hoiatusest läbi klõpsata. Kui mõlemad õnnestuvad ja dokument ikka ebaõnnestub, ei puuduta viga enam URL-i.