Οι σύνδεσμοι του SharePoint σπάνε μέσω VPN εξαιτίας δημοσιευμένων URL

Μια σελίδα SharePoint ανοίγει μέσω VPN και ο πρώτος σύνδεσμος εγγράφου αποτυγχάνει με όνομα που δεν βρέθηκε ποτέ στη γραμμή διευθύνσεων. Αυτό το κενό είναι όλο το πρόβλημα: η σελίδα ήρθε από μία URL και η υπηρεσία μορφοποίησε το επόμενο αίτημα από άλλη. Η δημοσιευμένη URL είναι απόφαση στην πλευρά του διακομιστή, άρα η διόρθωσή της στον πελάτη είναι το λάθος άκρο. Ελέγξτε ποιο όνομα επιστρέφει η υπηρεσία πριν αγγίξετε DNS ή διαδρομές.

Η πρώτη σελίδα και το επόμενο αίτημα χρησιμοποιούν διαφορετικά ονόματα

Ένας χρήστης που φτάνει στον διακομιστή μέσω της διεύθυνσης βλέπει μια αρχική σελίδα που λειτουργεί. Οι σύνδεσμοι εγγράφων σε αυτή τη σελίδα παράγονται από την URL που η υπηρεσία πιστεύει ότι δημοσιεύει, όχι από αυτό που πληκτρολόγησε το πρόγραμμα περιήγησης. Αν διαφέρουν, το επόμενο κλικ πηγαίνει σε όνομα που ο πελάτης δεν έχει επιλύσει ποτέ.

Η εισαγωγή της διεύθυνσης μία φορά δεν διορθώνει κάθε παραγόμενο σύνδεσμο, και ένας σελιδοδείκτης στη διεύθυνση κρύβει το πρόβλημα μέχρι να ανοίξει ένα έγγραφο.

Αυτή η αποτυχία διαβάζεται εύκολα λάθος ως πρόβλημα VPN επειδή εμφανίζεται μόνο αφού χρησιμοποιηθεί η σήραγγα. Στην πράξη η σήραγγα κάνει τη δουλειά της: μεταφέρει το αίτημα σε όνομα που δεν έχει λειτουργική διαδρομή ή αντίστοιχο πιστοποιητικό. Διαχωρίστε τα δύο ερωτήματα πριν αλλάξετε οποιοδήποτε από αυτά. Το ένα είναι πού πηγαίνει το πακέτο, το άλλο ποιο όνομα επέλεξε η υπηρεσία να δημοσιεύσει.

Τέσσερις έλεγχοι, ένα όνομα

Κάθε δημοσιευμένο όνομα πρέπει να περάσει τέσσερις ανεξάρτητους ελέγχους. Το DNS πρέπει να το επιλύσει για τον πραγματικό πελάτη, η δρομολόγηση και η πολιτική πρόσβασης πρέπει να επιτρέπουν τη διαδρομή, το TLS πρέπει να επικυρώσει αυτό το όνομα, και η υπηρεσία πρέπει να έχει ρυθμιστεί ώστε να το δημοσιεύει.

Μια αλλαγή σε έναν έλεγχο δεν εκτελεί τους άλλους. Η αποδοχή μιας προειδοποίησης πιστοποιητικού δεν είναι επισκευή επίλυσης ονόματος.

Ο πίνακας παρακάτω είναι η σειρά της λίστας ελέγχου. Σταματήστε στην πρώτη γραμμή που αποτυγχάνει, γιατί μια μεταγενέστερη διόρθωση δεν μπορεί να αντισταθμίσει ένα προγενέστερο κενό.

Διαβάστε το μοντέλο δημοσίευσης πριν το αλλάξετε

Οι αναπτύξεις του SharePoint Server διαφέρουν. Οι κλασικές εφαρμογές web μπορούν να χρησιμοποιούν εναλλακτικές αντιστοιχίσεις πρόσβασης, όπου η εσωτερική URL είναι αυτό που λαμβάνει ο διακομιστής και η δημόσια URL είναι αυτό που χρησιμοποιεί για να μορφοποιεί συνδέσμους. Οι συλλογές τοποθεσιών με όνομα κεντρικού υπολογιστή ακολουθούν άλλη προσέγγιση και, σύμφωνα με την καθοδήγηση της Microsoft, δεν μπορούν να χρησιμοποιούν AAM.

Η καθοδήγηση σχεδιασμού της Microsoft σημειώνει επίσης τις λειτουργίες AAM ως παρωχημένες και συνιστά συλλογές τοποθεσιών με όνομα κεντρικού υπολογιστή για νέο σχεδιασμό. Αυτό κάνει το μοντέλο ανάπτυξης ερώτημα για τον ιδιοκτήτη του, όχι προεπιλογή που την μπαλώνετε.

Καθορίστε ποιο μοντέλο χρησιμοποιείται πριν προτείνετε αλλαγή αντιστοίχισης. Η προσθήκη μιας καταχώρισης AAM σε ανάπτυξη με όνομα κεντρικού υπολογιστή δεν κάνει τίποτα, και η προσθήκη μίας σε κλασική ανάπτυξη αλλάζει κάθε επιστρεφόμενο σύνδεσμο ταυτόχρονα. Και οι δύο είναι αλλαγές διαμόρφωσης με μεγάλη εμβέλεια, γι' αυτό προετοιμάστε τις σε στάδια και κρατήστε σχέδιο επαναφοράς. Αυτό δεν είναι σύσταση να εισαγάγετε παλιές αντιστοιχίσεις σε σύγχρονο περιβάλλον.

Ακολουθήστε την αποτυχημένη λειτουργία, όχι την αρχική σελίδα

Καταγράψτε τον προορισμό που χρησιμοποίησε πραγματικά το αποτυχημένο αίτημα, την εφαρμογή πελάτη, την ώρα και το σφάλμα. Ένα πρόγραμμα περιήγησης και μια εφαρμογή επιφάνειας εργασίας μπορούν να ακολουθήσουν διαφορετικές διαδρομές διαμεσολαβητή, VPN ή ελέγχου ταυτότητας προς το ίδιο έγγραφο.

Το πρόγραμμα περιήγησης μπορεί να πετύχει ενώ ο πελάτης Office αποτυγχάνει, και αυτή η διαφορά είναι ένδειξη για το ποιο περιβάλλον επιλύει το όνομα.

Αν η URL και η δικτυακή παράδοση λειτουργούν και η υπηρεσία εξακολουθεί να απορρίπτει τη λειτουργία, το εναπομένον πρόβλημα είναι σε επίπεδο εφαρμογής. Τα δικαιώματα εγγράφων και η κατάσταση ολοκλήρωσης ανήκουν στον ιδιοκτήτη της υπηρεσίας, και μια διαδρομή VPN παρέχει συνδεσιμότητα, όχι άδεια.

Ελέγξτε την παράδοση από άκρη σε άκρη

Εκτελέστε τους ελέγχους με τη σειρά στον πελάτη που αποτυγχάνει: επιλύστε το δημοσιευμένο όνομα, ζητήστε τη σελίδα με αυτό το όνομα και μετά ζητήστε την URL του εγγράφου από την πηγή της σελίδας. Κάθε βήμα απομονώνει έναν έλεγχο.

Τρεις εντολές καλύπτουν την επίλυση, το TLS και τη διαδρομή του εγγράφου:

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.aspx

Αν η επίλυση αποτυγχάνει μόνο μέσω της σήραγγας, ύποπτη είναι η πολιτική split-DNS. Αν αποτυγχάνει το TLS, συγκρίνετε το όνομα του πιστοποιητικού με το δημοσιευμένο όνομα αντί να κάνετε κλικ για να συνεχίσετε. Αν και τα δύο πετύχουν και το έγγραφο εξακολουθεί να αποτυγχάνει, το σφάλμα δεν αφορά πλέον την URL.