SharePoint-keppelings brekke oer VPN troch publisearre URL's
In SharePoint-side dy't oer VPN laden wurdt, kin noch hieltyd dokumintkeppelings weromjaan op in namme dy't jo klant net oplosse kin. Kontrolearje DNS, rûte, TLS en de publisearre URL.
In SharePoint-side iepenet oer de VPN, en de earste dokumintkeppeling mislearret mei in namme dy't nea yn de adresbalke stie. Dat gat is it hiele probleem: de side kaam fan ien URL, en de tsjinst hat it folgjende fersyk fan in oare URL ôf formattearre. De publisearre URL is in beslút oan de tsjinstkant, dus it reparearjen op 'e klant is de ferkearde ein. Kontrolearje hokker namme de tsjinst weromjout foardat jo DNS of rûtes oanreitsje.
De earste side en it folgjende fersyk brûke ferskillende nammen
In brûker dy't de tsjinst fia it adres berikt, sjocht in wurkjende startside. De dokumintkeppelings op dy side wurde generearre út de URL dy't de tsjinst tinkt te publisearjen, net út wat de browser yntypke. As dy ferskille, giet de folgjende klik nei in namme dy't de klant nea oplost hat.
It adres ien kear ynfiere reparearret net elke generearre keppeling, en in blêdwizer nei it adres ferberget it probleem oant in dokumint iepene wurdt.
It mislearjen wurdt maklik ferkeard lêzen as in VPN-probleem, om't it pas ferskynt as de tunnel brûkt wurdt. Yn 'e praktyk docht de tunnel syn wurk: hy draacht it fersyk nei in namme sûnder wurkjend paad of sûnder passend sertifikaat. Skied de twa fragen foardat jo ien fan beide feroarje. De iene is wêr't it pakket hinne giet, de oare is hokker namme de tsjinst keas te publisearjen.
Fjouwer kontrôles, ien namme
Elke publisearre namme moat fjouwer ûnôfhinklike kontrôles trochstean. DNS moat it foar de echte klant oplosse, rûtebepaling en tagongbelied moatte it paad tastean, TLS moat foar dy namme falidearje, en de tsjinst moat konfigurearre wêze om it te publisearjen.
In feroaring oan ien kontrôle docht de oare net. In sertifikaatwarbering akseptearje is gjin reparaasje fan namme-oplossing.
De tabel hjirûnder is de folchoarder fan de checklist. Stop by de earste rige dy't mislearret, want in lettere reparaasje kin in earder gat net kompensearje.
| 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 |
Lês it publikaasjemodel foardat jo it feroarje
SharePoint Server-ymplementaasjes ferskille. Klassike webapplikaasjes kinne alternative tagongsmappings brûke, wêrby't in ynterne URL is wat de tsjinst ûntfangt en in publike URL is wat hy brûkt om keppelings te formaatjaan. Hostnamme-sidekolleksjes folgje in oare oanpak en kinne neffens de rjochtliningen fan Microsoft gjin AAM brûke.
De planningrjochtliningen fan Microsoft markearje AAM-funksjes ek as ferâldere en riede hostnamme-sidekolleksjes oan foar nije planning. Dat makket it ymplementaasjemodel in fraach foar syn eigner, net in standertwearde dy't jo pleisterje.
Stel fêst hokker model brûkt wurdt foardat jo in mappingferoaring foarstelle. In AAM-ynfier tafoegje oan in hostnamme-ymplemintaasje docht neat, en ien tafoegje oan in klassike ymplemintaasje feroaret elke weromjûn keppeling tagelyk. Beide binne konfiguraasjefoarings mei in grutte ynfloed, dus meitsje se yn fazen klear en hâld in weromsetplan. Dit is gjin oanbefelling om âlde mappings yn in moderne omjouwing yn te bringen.
Folgje de mislearre bewurking, net de startside
Skriuw de bestimming op dy't it mislearre fersyk echt brûkte, de klantapplikaasje, de tiid en de flater. In browser en in buroblêdapplikaasje kinne ferskillende proxy-, VPN- of ferifikaasjepaden nei itselde dokumint nimme.
De browser kin slagje wylst de Office-klant mislearret, en dat ferskil is in oanwizing hokker kontekst de namme oplost.
As de URL en de netwurk-oerdracht beide wurkje en de tsjinst de bewurking noch altyd wegeret, is it oerbleaune probleem op applikaasjenivo. Dokumintrjochten en de check-outstatus hearre by de eigner fan de tsjinst, en in VPN-rûte jout ferbining, net tastimming.
Kontrolearje de oerdracht fan begjin oant ein
Fier de kontrôles yn folchoarder út op de klant dy't mislearret: los de publisearre namme op, freegje de side op dy namme, freegje dan de dokumint-URL út de boarne fan de side. Eltse stap isolearret ien kontrôle.
Trije opdrachten dekke oplossing, TLS en it dokumintpaad:
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.aspxAs de oplossing allinnich fia de tunnel mislearret, is it split-DNS-belied de fertochte. As TLS mislearret, ferlykje dan de sertifikaatnamme mei de publisearre namme ynstee fan troch te klikken. As beide slagje en it dokumint mislearret noch, giet de flater net mear oer de URL.