STUN Server: τι είναι, πώς λειτουργεί και που χρησιμοποιείται

Τι είναι το STUN Server

STUN Server (Session Traversal Utilities for NAT) — είναι μια υπηρεσία δικτύου που λειτουργεί σύμφωνα με το πρωτόκολλο που ορίζεται στο RFC 5389 και ενημερώθηκε στο RFC 8489. Η κύρια αποστολή του εξυπηρετητή STUN είναι να παρέχει στον πελάτη πληροφορίες σχετικά με τη δική του δημόσια διεύθυνση IP και θύρα που είναι ορατές από το εξωτερικό δίκτυο, καθώς και να προσδιορίσει τον τύπο της συσκευής NAT μεταξύ του πελάτη και του διαδικτύου.

Η αρχιτεκτονική του STUN περιλαμβάνει δύο στοιχεία: τον πελάτη STUN ενσωματωμένο στην εφαρμογή (για παράδειγμα, πρόγραμμα περιήγησης ή εγγενή εφαρμογή WebRTC) και τον εξυπηρετητή STUN τοποθετημένο στο δημόσιο δίκτυο. Ο πελάτης στέλνει ένα STUN Binding Request στον εξυπηρετητή, ο οποίος στην απάντηση υποδεικνύει τη διεύθυνση IP και τη θύρα της πηγής του αιτήματος — δηλαδή τις δημόσιες διευθύνσεις του πελάτη όπως τις βλέπει ο εξυπηρετητής. Συγκρίνοντας αυτά τα δεδομένα με τις τοπικές διευθύνσεις, ο πελάτης μπορεί να προσδιορίσει ποιος τύπος NAT χρησιμοποιείται στο δίκτυό του.

Πρωτόκολλο STUN

STUN λειτουργεί μέσω UDP (θύρα 3478 από προεπιλογή) ή TCP (θύρα 3478 ή 5349 για TLS). Ένα μήνυμα STUN αποτελείται από μια κεφαλίδα 20 byte και ένα μεταβλητό αριθμό γνωρισμάτων. Η κεφαλίδα περιέχει τον τύπο μηνύματος (Binding Request, Binding Response, Binding Error Response), το μήκος και ένα μοναδικό αναγνωριστικό συναλλαγής (96 bit) που επιτρέπει την αντιστοίχιση αιτημάτων και απαντήσεων. Κάθε Binding Response περιέχει το γνώρισμα XOR-MAPPED-ADDRESS — την εξωτερική διεύθυνση του πελάτη, κωδικοποιημένη με συγκάλυψη για προστασία από επιθέσεις που βασίζονται στην υποκλοπή κίνησης STUN.

Πώς λειτουργεί ο εξυπηρετητής STUN

Ο εξυπηρετητής STUN λειτουργεί με απλό πρωτόκολλο αίτησης-απάντησης. Ο πελάτης που βρίσκεται πίσω από NAT σχηματίζει ένα Binding Request και το στέλνει στον εξυπηρετητή STUN. Ο εξυπηρετητής λαμβάνει το πακέτο, εξάγει από την κεφαλίδα UDP τη διεύθυνση IP πηγής και τη θύρα αποστολέα, στη συνέχεια σχηματίζει μια Binding Response, συσκευάζοντας αυτή τη διεύθυνση στο γνώρισμα XOR-MAPPED-ADDRESS. Η απάντηση στέλνεται πίσω στη διεύθυνση πηγής του αιτήματος.

Ο πελάτης λαμβάνει την απάντηση και εξάγει το XOR-MAPPED-ADDRESS, το οποίο περιέχει την εξωτερική διεύθυνση IP και θύρα που εκχωρήθηκαν από τη συσκευή NAT. Στη συνέχεια ο πελάτης συγκρίνει αυτή τη διεύθυνση με την τοπική του (RFC 1919 — ιδιωτική) διεύθυνση. Αν οι διευθύνσεις ταιριάζουν — ο πελάτης δεν βρίσκεται πίσω από NAT. Αν διαφέρουν — ο πελάτης είναι πίσω από NAT και η εξωτερική διεύθυνση χρησιμοποιείται ως υποψήφιος για ICE (Interactive Connectivity Establishment) στο WebRTC.

Διαδικασία ανίχνευσης NAT (NAT Discovery)

Ο εξυπηρετητής STUN επιτρέπει τον προσδιορισμό του τύπου NAT μέσω μιας σειράς δοκιμαστικών αιτημάτων. Ο πελάτης στέλνει αιτήματα με διαφορετικές σημαίες (CHANGE-REQUEST) και αναλύει τις απαντήσεις. Ο πλήρης κύκλος ανίχνευσης περιλαμβάνει την αποστολή αιτημάτων σε διαφορετικές διευθύνσεις IP και θύρες του εξυπηρετητή STUN. Αν ο εξυπηρετητής απαντά σε αίτημα με τροποποιημένη θύρα — NAT τύπου Restricted Cone. Αν δεν απαντά σε αίτημα με τροποποιημένη θύρα και IP — NAT τύπου Symmetric. Αυτή η πληροφορία είναι κρίσιμη για την επιλογή στρατηγικής ICE στο WebRTC.

Εξυπηρετητής STUN και τύποι NAT

Ο εξυπηρετητής STUN είναι σε θέση να προσδιορίσει τέσσερις κύριους τύπους NAT, καθένας από τους οποίους επηρεάζει διαφορετικά τη δυνατότητα δημιουργίας σύνδεσης P2P. Ο τύπος NAT καθορίζει αν το STUN μπορεί να εξασφαλίσει άμεση σύνδεση μεταξύ δύο πελατών. Από τον τύπο NAT εξαρτάται ποιος υποψήφιος ICE — host, server reflexive ή relay — θα χρησιμοποιηθεί για τη σύνδεση.

Symmetric NAT — ο μοναδικός τύπος με τον οποίο το STUN δεν μπορεί να αντιμετωπίσει. Στο Symmetric NAT, κάθε νέο αίτημα προς έναν νέο υπολογιστή-στόχο λαμβάνει διαφορετική εξωτερική διεύθυνση (IP και/ή θύρα). Δεδομένου ότι ο εξυπηρετητής STUN αναφέρει τη διεύθυνση για τη σύνδεση με τον ίδιο τον εξυπηρετητή STUN, αυτή η διεύθυνση είναι ακατάλληλη για σύνδεση με άλλον πελάτη. Σε τέτοιες περιπτώσεις, στο WebRTC χρησιμοποιείται εξυπηρετητής TURN για την αναμετάδοση κίνησης. Σύμφωνα με έρευνες (Ford et al., RFC 3489, 2003), περίπου 8–10% όλων των συσκευών NAT στο διαδίκτυο είναι συμμετρικές.

Χρήση εξυπηρετητή STUN στο WebRTC

Ο εξυπηρετητής STUN ενσωματώνεται στο WebRTC μέσω της ρύθμισης RTCPeerConnection. Το πρόγραμμα περιήγησης ή η εγγενής εφαρμογή χρησιμοποιεί STUN για τη συλλογή υποψηφίων ICE, οι οποίοι στη συνέχεια ανταλλάσσονται μέσω Signaling Server. Στη ρύθμιση WebRTC, ο εξυπηρετητής STUN καθορίζεται στον πίνακα iceServers με πρόθεμα stun: για UDP ή stuns: για σύνδεση TLS.

Ας δούμε ένα παράδειγμα ρύθμισης εξυπηρετητή STUN σε JavaScript κατά τη δημιουργία RTCPeerConnection για μια εφαρμογή WebRTC.

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("υποψήφιος ICE:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Σε αυτό το παράδειγμα χρησιμοποιούνται οι δημόσιοι εξυπηρετητές STUN της Google (stun.l.google.com:19302). Κατά τη δημιουργία offer ή answer, το πρόγραμμα περιήγησης στέλνει αυτόματα ένα STUN Binding Request στους καθορισμένους εξυπηρετητές, λαμβάνει την εξωτερική διεύθυνση (server reflexive candidate) και την προσθέτει στη λίστα υποψηφίων ICE. Μετά τη συλλογή όλων των υποψηφίων, αποστέλλονται στον απομακρυσμένο συνεργάτη μέσω Signaling Server για προσπάθεια δημιουργίας άμεσης P2P σύνδεσης.

Τύποι υποψηφίων ICE και STUN

Στη διαδικασία ICE υπάρχουν τρεις τύποι υποψηφίων: host (τοπική διεύθυνση), srflx (server reflexive — ληφθείσα από STUN) και relay (αναμεταδομένη μέσω TURN). Ο εξυπηρετητής STUN εξασφαλίζει την εμφάνιση υποψηφίων srflx, οι οποίοι έχουν υψηλότερη προτεραιότητα από το relay, καθώς η σύνδεση μέσω STUN είναι άμεση και δεν απαιτεί αναμετάδοση. Η διαδικασία ICE ελέγχει όλους τους συνδυασμούς υποψηφίων (τοπικών και ληφθέντων από STUN) και των δύο μερών, ξεκινώντας από τις υψηλότερες προτεραιότητες.

Περιορισμοί πρωτοκόλλου STUN

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

Ο δεύτερος περιορισμός σχετίζεται με το γεγονός ότι το STUN δεν παρέχει αναμετάδοση δεδομένων. Αν η άμεση P2P σύνδεση είναι αδύνατη (και τα δύο μέρη βρίσκονται πίσω από Symmetric NAT), το STUN δεν προσφέρει εναλλακτική διαδρομή για μεταφορά δεδομένων. Σε αυτή την περίπτωση απαιτείται εξυπηρετητής TURN, ο οποίος λειτουργεί ως αναμεταδότης κίνησης πολυμέσων μεταξύ των μερών, λαμβάνοντας δεδομένα από έναν συμμετέχοντα και στέλνοντάς τα στον άλλο μέσω της δημόσιας διεύθυνσης IP του.

• Symmetric NAT — το STUN δεν λειτουργεί με συμμετρικό NAT, καθώς η εξωτερική διεύθυνση είναι μοναδική για κάθε υπολογιστή-στόχο και δεν μπορεί να επαναχρησιμοποιηθεί για P2P.
• Firewall Deep Packet Inspection — ορισμένα τείχη προστασίας αποκλείουν την κίνηση STUN ανιχνεύοντάς την από υπογραφές πρωτοκόλλου σε πακέτα UDP στη θύρα 3478.
• IPv6 — στα δίκτυα IPv6, το NAT συνήθως δεν χρησιμοποιείται, επομένως το STUN δεν είναι απαραίτητο, αλλά το WebRTC σε IPv6 μπορεί να χρησιμοποιήσει host υποψηφίους χωρίς ανάγκη για STUN ή TURN.
• Εξάρτηση από διαθεσιμότητα — ο εξυπηρετητής STUN πρέπει να είναι προσβάσιμος από τον πελάτη στη φάση δημιουργίας σύνδεσης, διαφορετικά οι υποψήφιοι srflx δεν θα συλλεχθούν.
• Ασφάλεια — το πρωτόκολλο STUN είναι ευάλωτο σε επίθεση ενίσχυσης (amplification attack) αν ο εξυπηρετητής είναι λανθασμένα ρυθμισμένος και απαντά σε αιτήματα με πλαστή διεύθυνση πηγής.

Παρά τους περιορισμούς, ο εξυπηρετητής STUN παραμένει κρίσιμο στοιχείο της υποδομής WebRTC. Στις περισσότερες περιπτώσεις (80–90%), η άμεση P2P σύνδεση μπορεί να επιτευχθεί με τη βοήθεια του STUN, επιτρέποντας την αποφυγή κόστους αναμετάδοσης TURN και μειώνοντας την καθυστέρηση μεταφοράς δεδομένων πολυμέσων. Για δημόσιες εφαρμογές WebRTC, συνιστάται η χρήση συνδυασμού εξυπηρετητών STUN και TURN με αυτόματη επαναφορά για εγγύηση σύνδεσης υπό όλες τις συνθήκες δικτύου.