SharePoint-linkit katkeavat VPN:n yli julkaistujen URL-osoitteiden takia
VPN:n kautta latautuva SharePoint-sivu voi yhä palauttaa dokumenttilinkkejä nimellä, jota asiakasohjelmasi ei pysty selvittämään. Tarkista DNS, reitti, TLS ja julkaistu URL-osoite.
SharePoint-sivu avautuu VPN:n kautta, ja ensimmäinen dokumenttilinkki epäonnistuu nimellä, jota ei koskaan ollut osoitepalkissa. Tämä aukko on koko ongelma: sivu tuli yhdestä URL-osoitteesta ja palvelu muotoili seuraavan pyynnön toisesta. Julkaistu URL-osoite on palvelinpuolen päätös, joten sen korjaaminen asiakkaassa on väärä pää. Tarkista, minkä nimen palvelu palauttaa, ennen kuin kosket DNS:ään tai reitteihin.
Ensimmäinen sivu ja seuraava pyyntö käyttävät eri nimiä
Käyttäjä, joka saapuu palvelimelle osoitteen kautta, näkee toimivan etusivun. Sen sivun dokumenttilinkit luodaan URL-osoitteesta, jonka palvelu uskoo julkaisevansa, eikä siitä, mitä selain kirjoitti. Jos ne eroavat, seuraava napsautus menee nimelle, jota asiakasohjelma ei ole koskaan selvittänyt.
Osoitteen kirjoittaminen kerran ei korjaa jokaista luotua linkkiä, ja osoitteen kirjanmerkki piilottaa ongelman, kunnes dokumentti avataan.
Tämä vika tulkitaan helposti väärin VPN-ongelmaksi, koska se ilmenee vasta, kun tunneli on käytössä. Käytännössä tunneli tekee työnsä: se kuljettaa pyynnön nimelle, jolla ei ole toimivaa polkua tai vastaavaa varmennetta. Erottele kaksi kysymystä ennen kuin muutat kumpaakaan. Toinen on, minne paketti menee, toinen on, minkä nimen palvelu valitsi julkaistavaksi.
Neljä valvontaa, yksi nimi
Jokaisen julkaistun nimen on läpäistävä neljä riippumatonta valvontaa. DNS:n on selvitettävä se todelliselle asiakkaalle, reitityksen ja käyttöoikeuskäytännön on sallittava polku, TLS:n on vahvistettava kyseinen nimi, ja palvelu on määritettävä julkaisemaan se.
Yhden valvonnan muutos ei suorita muita. Varmennevaroituksen hyväksyminen ei ole nimenselvityksen korjaus.
Alla oleva taulukko on tarkistuslistan järjestys. Pysähdy ensimmäiseen riviin, joka epäonnistuu, koska myöhempi korjaus ei voi korvata aiempaa aukkoa.
| 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 |
Lue julkaisumalli ennen sen muuttamista
SharePoint Server -käyttöönotot eroavat toisistaan. Klassiset verkkosovellukset voivat käyttää vaihtoehtoisia käyttöoikeusmäärityksiä, joissa sisäinen URL-osoite on se, minkä palvelin vastaanottaa, ja julkinen URL-osoite se, mitä se käyttää linkkien muotoiluun. Isäntänimiset sivustokokoelmat noudattavat eri lähestymistapaa, eivätkä ne Microsoftin ohjeiden mukaan voi käyttää AAM:ää.
Microsoftin suunnitteluohjeet merkitsevät myös AAM-ominaisuudet vanhentuneiksi ja suosittelevat isäntänimisiä sivustokokoelmia uuteen suunnitteluun. Tämä tekee käyttöönottomallista sen omistajan kysymyksen, ei oletusarvoa, jota sinä paikkaat.
Selvitä, mikä malli on käytössä, ennen kuin ehdotat määrityksen muutosta. AAM-merkinnän lisääminen isäntänimiseen käyttöönottoon ei tee mitään, ja yhden lisääminen klassiseen käyttöönottoon muuttaa kaikki palautetut linkit kerralla. Molemmat ovat laajan vaikutuksen konfiguraatiomuutoksia, joten valmistele ne vaiheittain ja pidä palautussuunnitelma. Tämä ei ole suositus tuoda vanhoja määrityksiä nykyaikaiseen ympäristöön.
Seuraa epäonnistunutta toimintoa, älä etusivua
Kirjaa kohde, jota epäonnistunut pyyntö todella käytti, asiakassovellus, aika ja virhe. Selain ja työpöytäsovellus voivat kulkea eri välityspalvelin-, VPN- tai todennuspolkuja samaan dokumenttiin.
Selain voi onnistua, kun Office-asiakas epäonnistuu, ja tämä ero on vihje siitä, mikä konteksti selvittää nimen.
Jos URL-osoite ja verkon luovutus molemmat toimivat ja palvelu yhä hylkää toiminnon, jäljellä oleva ongelma on sovellustasolla. Dokumenttien käyttöoikeudet ja uloskuittauksen tila kuuluvat palvelun omistajalle, ja VPN-reitti tarjoaa yhteyden, ei käyttöoikeutta.
Tarkista luovutus päästä päähän
Suorita tarkistukset järjestyksessä asiakkaalla, joka epäonnistuu: selvitä julkaistu nimi, pyydä sivu sillä nimellä ja pyydä sitten dokumentin URL-osoite sivun lähdekoodista. Jokainen vaihe eristää yhden valvonnan.
Kolme komentoa kattavat selvityksen, TLS:n ja dokumentin polun:
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.aspxJos selvitys epäonnistuu vain tunnelin kautta, epäilty on split-DNS-käytäntö. Jos TLS epäonnistuu, vertaa varmenteen nimeä julkaistuun nimeen sen sijaan, että napsautat varoituksen läpi. Jos molemmat onnistuvat ja dokumentti yhä epäonnistuu, virhe ei enää koske URL-osoitetta.