SharePoint saites VPN tīklā lūzt publicēto URL dēļ
SharePoint lapa, kas ielādēta VPN, joprojām var atgriezt dokumentu saites ar nosaukumu, ko jūsu klients nevar atrisināt. Pārbaudiet DNS, maršrutu, TLS un publicēto URL.
SharePoint lapa atveras VPN, un pirmā dokumenta saite neizdodas ar nosaukumu, kas nekad nav bijis adreses joslā. Šī atstarpe ir visa problēma: lapa nāca no viena URL, un pakalpojums formatēja nākamo pieprasījumu no cita. Publicētais URL ir servera puses lēmums, tāpēc labot to klientā ir nepareizais gals. Pārbaudiet, kādu nosaukumu pakalpojums atgriež, pirms aiztiekat DNS vai maršrutus.
Pirmā lapa un nākamais pieprasījums izmanto dažādus nosaukumus
Lietotājs, kurš sasniedz serveri ar adresi, redz strādājošu sākumlapu. Šīs lapas dokumentu saites tiek ģenerētas no URL, kuru pakalpojums uzskata sevi publicējam, nevis no tā, ko ierakstīja pārlūks. Ja tie atšķiras, nākamais klikšķis dodas uz nosaukumu, kuru klients nekad nav atrisinājis.
Adreses ievadīšana vienreiz nesalabo katru ģenerēto saiti, un adreses grāmatzīme slēpj problēmu līdz dokumenta atvēršanai.
Šo kļūdu ir viegli nepareizi nolasīt kā VPN problēmu, jo tā parādās tikai pēc tuneļa lietošanas. Patiesībā tunelis dara savu darbu: tas nes pieprasījumu uz nosaukumu, kuram nav strādājoša ceļa vai atbilstoša sertifikāta. Atdaliet abus jautājumus, pirms maināt kādu no tiem. Viens ir, kur pakete iet, otrs ir, kādu nosaukumu pakalpojums izvēlējās publicēt.
Četras kontroles, viens nosaukums
Ikam publicētam nosaukumam jāiztur četras neatkarīgas kontroles. DNS tam jāatrisina faktiskajam klientam, maršrutēšanai un piekļuves politikai jāatļauj ceļš, TLS tam jāvalidē nosaukums, un pakalpojumam jābūt konfigurētam to publicēt.
Izmaiņa vienā kontrolē neveic pārējās. Sertifikāta brīdinājuma pieņemšana nav nosaukuma atrisināšanas labojums.
Zemāk esošā tabula ir kontrolsaraksta secība. Apstājieties pirmajā rindā, kas neizdodas, jo vēlāks labojums nevar kompensēt agrāku trūkumu.
| 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 |
Izlasiet publicēšanas modeli pirms tā maiņas
SharePoint Server izvietojumi atšķiras. Klasiskās tīmekļa lietojumprogrammas var izmantot alternatīvus piekļuves kartējumus, kur iekšējais URL ir tas, ko serveris saņem, un publiskais URL ir tas, ko tas izmanto saišu formatēšanai. Resursdatora nosaukuma vietņu kolekcijas izmanto citu pieeju un saskaņā ar Microsoft norādēm nevar izmantot AAM.
Microsoft plānošanas norādes arī atzīmē AAM funkcijas kā novecojušas un jaunai plānošanai iesaka resursdatora nosaukuma vietņu kolekcijas. Tas padara izvietošanas modeli par jautājumu tā īpašniekam, nevis noklusējumu, ko jūs lāpāt.
Nosakiet, kurš modelis tiek izmantots, pirms ierosināt kartējuma izmaiņu. AAM ieraksta pievienošana resursdatora nosaukuma izvietojumam neko nedara, un viena pievienošana klasiskajam izvietojumam maina visas atgrieztās saites uzreiz. Abas ir konfigurācijas izmaiņas ar plašu ietekmi, tāpēc sagatavojiet tās pa posmiem un saglabājiet atritināšanas plānu. Šis nav ieteikums ieviest vecus kartējumus modernā vidē.
Sekojiet neizdevušajai darbībai, nevis sākumlapai
Pierakstiet galamērķi, ko neizdevušais pieprasījums faktiski izmantoja, klienta lietojumprogrammu, laiku un kļūdu. Pārlūks un darbvirsmas lietojumprogramma var iet dažādus starpniekservera, VPN vai autentifikācijas ceļus uz vienu un to pašu dokumentu.
Pārlūks var gūt panākumus, kamēr Office klients neizdodas, un šī atšķirība ir pavediens, kurš konteksts atrisina nosaukumu.
Ja URL un tīkla nodošana abi darbojas un pakalpojums joprojām noraida darbību, atlikušā problēma ir lietojumprogrammas līmenī. Dokumentu atļaujas un norēķinu statuss pieder pakalpojuma īpašniekam, un VPN maršruts nodrošina savienojamību, nevis atļauju.
Pārbaudiet nodošanu no sākuma līdz beigām
Izpildiet pārbaudes secīgi klientā, kas neizdodas: atrisiniet publicēto nosaukumu, pieprasiet lapu ar šo nosaukumu, pēc tam pieprasiet dokumenta URL no lapas pirmkoda. Katrs solis izolē vienu kontroli.
Trīs komandas aptver atrisināšanu, TLS un dokumenta ceļu:
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.aspxJa atrisināšana neizdodas tikai caur tuneli, aizdomās turamais ir split-DNS politika. Ja TLS neizdodas, salīdziniet sertifikāta nosaukumu ar publicēto nosaukumu, nevis klikšķiniet tam cauri. Ja abi izdodas un dokuments joprojām neizdodas, kļūda vairs nav par URL.