Στο Dante 1.4.4, οι κανόνες πελάτη δέχονται τη σύνδεση πριν από τη διαπραγμάτευση SOCKS, ενώ οι κανόνες SOCKS αποφασίζουν ποια πιστοποιημένα αιτήματα μπορούν να συνεχίσουν. Μια σύνδεση από επιτρεπόμενη προέλευση μπορεί ακόμη να απαιτεί όνομα χρήστη στο δεύτερο στάδιο.

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

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

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

Διατηρήστε τα όρια των αιτημάτων

Μετά τον υπάρχοντα περιοριστικό κανόνα πελάτη, απαιτήστε τον λογαριασμό στην επιτρεπόμενη διαδρομή SOCKS:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

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

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

Δοκιμάστε χωριστά τη διαπραγμάτευση και την πρόσβαση

Πριν από την εκκίνηση, ελέγξτε το αρχείο με τη λειτουργία ελέγχου ρυθμίσεων του εγκατεστημένου διακομιστή. Έπειτα χρησιμοποιήστε εξουσιοδοτημένο πελάτη που υποστηρίζει πράγματι διαπραγμάτευση SOCKS5 με όνομα χρήστη και κωδικό. Ελέγξτε απουσία στοιχείων, λανθασμένα στοιχεία και επιτρεπόμενο λογαριασμό που ζητά απαγορευμένο στόχο.

Η υποδιαπραγμάτευση ονόματος χρήστη και κωδικού του RFC 1929 δεν κρυπτογραφεί τον κωδικό. Μια μεταγενέστερη συνεδρία HTTPS με τον προορισμό δεν προστατεύει εκείνη την προηγούμενη ανταλλαγή με τον proxy. Χρησιμοποιήστε κατάλληλα προστατευμένη διαδρομή πελάτη–διακομιστή.

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

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