SNX στο Linux: βιβλιοθήκες 32 bit και ένας επιλυτής που επανέρχεται

Το SNX στο Linux αποτυγχάνει στον φορτωτή, στον πίνακα δρομολόγησης ή στον επιλυτή, και καθεμία από αυτές τις αστοχίες μοιάζει με πρόβλημα σύνδεσης. Δουλέψτε τα τέσσερα συμπτώματα με τη σειρά.

Το SSL Network Extender της Check Point αποτυγχάνει στο Linux με τέσσερις αναγνωρίσιμους τρόπους, και τρεις από αυτούς διαβάζονται λανθασμένα ως πρόβλημα σύνδεσης. Είτε το δυαδικό δεν ξεκινά, είτε ξεκινά και δεν αφήνει καμία διαδρομή, είτε συνδέεται και η επίλυση ονομάτων πεθαίνει, είτε η πύλη του προγράμματος περιήγησης λειτουργεί ενώ η γραμμή εντολών όχι. Δουλέψτε τα με αυτή τη σειρά, γιατί καθένα είναι η συνθήκη εισόδου για το επόμενο.

Σύμπτωμα πρώτο: ο φορτωτής αρνείται πριν τη σύνδεση

Ο εγκαταστάτης που κατεβάζεται από το τείχος προστασίας αφήνει ένα δυαδικό 32 bit με setuid-root στο /usr/bin/snx. Σε διανομή 64 bit δεν εκτελείται μέχρι να ενεργοποιηθεί η αρχιτεκτονική i386 και να υπάρχουν οι βιβλιοθήκες με τις οποίες συνδέεται.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

Μια κενή λίστα not found είναι η πύλη για όλα τα επόμενα. Το ακριβές σύνολο πακέτων αλλάζει μεταξύ εκδόσεων: μια αναφορά που λειτουργούσε χρειαζόταν libstdc++5:i386, libx11-6:i386 και libpam0g:i386, μια άλλη χρειαζόταν επίσης libstdc++6:i386. Διαβάστε το ldd αντί να αντιγράφετε μια λίστα πακέτων από οδηγό γραμμένο για άλλη διανομή.

Αν το snx δεν βρίσκεται καθόλου, ο εγκαταστάτης δεν ολοκληρώθηκε ποτέ ή εγκαταστάθηκε κάπου έξω από το PATH σας. Αυτή είναι διαφορετική αστοχία, και αξίζει να την επιβεβαιώσετε πριν προσθέσετε αρχιτεκτονικές στο σύστημα. Ελέγξτε με το command -v snx και κοιτάξτε στον κατάλογο που ανέφερε ο εγκαταστάτης. Η προσθήκη πακέτων i386 σε μηχάνημα όπου το δυαδικό απλώς απουσιάζει δεν διορθώνει τίποτα.

Σύμπτωμα δεύτερο: η σύνδεση πετυχαίνει και τίποτα δεν δρομολογείται

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

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Χρησιμοποιήστε το snx -d για αποσυναρμολόγηση. Το σκότωμα της διεργασίας αφήνει πίσω τη διεπαφή και τις διαδρομές της, και η επόμενη προσπάθεια αποτυγχάνει τότε για λόγο που δεν έχει καμία σχέση με τα διαπιστευτήρια. Η πρώτη σύνδεση καταγράφει επίσης μια υπογραφή διακομιστή στο /etc/snx/, γι’ αυτό ένα μη επιτηρούμενο σενάριο μπορεί να χρειάζεται μία διαδραστική εκτέλεση πριν μπορέσει να λειτουργήσει καθόλου. Διαγράψτε αυτή την κατάσταση μόνο όταν σκοπεύετε να εγκρίνετε ξανά τον διακομιστή.

Σύμπτωμα τρίτο: τα ονόματα επιλύονται μέχρι να σηκωθεί το τούνελ

Αυτό είναι εκείνο που σπάει σιωπηλά. Το snx γράφει τους ωθούμενους διακομιστές DNS απευθείας στο /etc/resolv.conf. Όπου αυτή η διαδρομή είναι συμβολικός σύνδεσμος μέσα στο /run/systemd/resolve/, η αλλαγή μπορεί να χαθεί στο επόμενο συμβάν του επιλυτή, και μετά από αποσύνδεση οι ωθούμενες καταχωρίσεις μπορούν εξίσου καλά να μείνουν.

Δύο ρυθμίσεις λειτουργούν, και η επιλογή πρέπει να είναι σκόπιμη και όχι ό,τι πρότεινε το πρώτο αποτέλεσμα αναζήτησης:

  • Πάρτε το αρχείο: αντικαταστήστε τον συμβολικό σύνδεσμο με στατικό αρχείο και εγκαταστήστε το libnss-resolve μαζί με την παραλλαγή του για i386, ώστε η υπηρεσία ονομάτων να έχει ακόμη εφεδρεία όταν το αρχείο ξαναγράφεται από κάτω.
  • Κρατήστε το systemd-resolved ως ιδιοκτήτη και καταχωρίστε τον σύνδεσμο του τούνελ: resolvectl dns tunsnx 10.0.0.10, μετά resolvectl domain tunsnx corp.example, και επιβεβαιώστε με το resolvectl status.

Καταγράψτε τους διακομιστές ονομάτων πριν το VPN πριν συνδεθείτε. Αν επεξεργαστείτε το αρχείο με το χέρι, η αφαίρεση των ωθούμενων καταχωρίσεων μετά είναι μέρος της διαδικασίας, όχι προαιρετικός καθαρισμός, γιατί ένα φορητό που κρατά το εταιρικό DNS μετά την αποσύνδεση δεν θα μπορεί να επιλύσει τίποτα άλλο.

Σύμπτωμα τέταρτο: η πύλη λειτουργεί και το CLI όχι

Πρόσφατες εκδόσεις του τείχους προστασίας μετακίνησαν το middleware από το πρόγραμμα περιήγησης σε τοπικό δαίμονα Java, οπότε η πύλη μιλά με τοπικό πράκτορα στη θύρα 14186. Αυτή η διεύθυνση χρειάζεται εξαίρεση πιστοποιητικού στο πρόγραμμα περιήγησης και μια διεργασία που τρέχει.

ps ax | grep cshell
/usr/bin/cshell/launcher

Η γραμμή εντολών είναι ξεχωριστή διαδρομή: snx -s vpn.example.com -u user, με το ~/.snxrc να κρατά τον διακομιστή, το όνομα χρήστη και την προτίμηση επαναπιστοποίησης. Μια συνεδρία πύλης που λειτουργεί δεν λέει τίποτα για το αν το CLI έχει εγκατασταθεί σωστά, και ο γυμνός πελάτης δεν χειρίζεται κωδικούς μίας χρήσης.

Η συντόμευση με κοντέινερ που κοστίζει περισσότερο απ’ όσο γλιτώνει

Το snx ελέγχει για το άρθρωμα tun, το φορτώνει όταν λείπει, δημιουργεί διεπαφή τούνελ, ξαναγράφει διαδρομές και σπρώχνει την κίνηση μέσα από αυτό. Το να αναπαράγετε αυτό μέσα σε κοντέινερ σημαίνει προσάρτηση των /dev και /lib/modules και παραχώρηση ευρέων δυνατοτήτων, που δίνει στο κοντέινερ το μεγαλύτερο μέρος της διαχείρισης δικτύου του κεντρικού υπολογιστή.

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

Σχετικά άρθρα