Το προφίλ μας στο Google Plus
0

Η ζωή με τον OpenVPN-enabled router μας

Στο τεύχος 048 δείξαμε πώς στήνουμε έναν OpenVPN Access Server στο cloud και στη συνέχεια πώς ρυθμίζουμε έναν τοπικό pfSense-based router, ώστε να λειτουργεί ως πελάτης του. Το αποτέλεσμα είναι ότι όλα τα μηχανήματα και οι συσκευές πίσω από τον router βγαίνουν στο Internet μέσω ενός ασφαλούς κρυπτογραφημένου τούνελ. Θα περίμενε Κανείς ότι δεν θα είχαμε κάτι άλλο να συζητήσουμε επί του θέματος. Θα περίμενε λάθος, ο Κανείς αυτός.

Έτσι είναι τα πράγματα με το deltaHacker, φίλες και φίλοι. Συχνά ξεκινάμε με ένα ενδιαφέρον, κατά την κρίση μας, θέμα, μετά από ένα ή περισσότερα άρθρα φτάνουμε σε ένα ικανοποιητικό σημείο όπου όλα λειτουργούν σωστά κι όλοι είναι ευχαριστημένοι, ξαφνικά όμως συνειδητοποιούμε ότι υπάρχει κι ένα ολόκληρο υπό-σύμπαν για το οποίο δεν έχουμε γράψει ούτε μια λέξη ακόμα — ενώ θα έπρεπε. Αυτή τη φορά, αφού φροντίσαμε ώστε όλοι οι πελάτες του pfSense να βγαίνουν στο Internet *αυτόματα* μέσω του απομακρυσμένου OpenVPN Access Server, σκεφτήκαμε ότι είναι αδύνατον να κλείσουμε το θέμα αν πρώτα δεν δείξουμε πώς:

  • βελτιστοποιούμε τη συμπεριφορά του Access Server,
  • φέρνουμε στα μέτρα μας τη συμπεριφορά του pfSense router,
  • βεβαιωνόμαστε ότι όλα δουλεύουν όπως ακριβώς θέλουμε.

Χωρίς άλλη καθυστέρηση ξεκινάμε με το NAT, ένα χρεωστούμενο από το σχετικό άρθρο στο τεύχος 048.

Τι είναι αυτό το NAT και γιατί μας απασχόλησε;
Μετά την πρώτη εγκαθίδρυση σύνδεσης μεταξύ pfSense router και OpenVPN Access Server, θα θυμόσαστε ίσως ότι όλες οι συσκευές πίσω από τον router έδειχναν ανίκανες να βγουν στο Internet. Η κατάσταση ομαλοποιήθηκε μόνον αφού προσθέσαμε στο firewall έναν κανόνα Outbound NAT για το DefiantVPN (έτσι έχουμε ονομάσει το network interface για τις συνδέσεις προς τον Access Server).

Γενικά, με τον όρο Network Address Translation ή απλά NAT αναφερόμαστε σε μεθόδους αντιστοίχισης μεταξύ δύο διαφορετικών IP spaces. Οι αντιστοιχίσεις πραγματοποιούνται αλλάζοντας κατάλληλα τα headers στα πακέτα IP, καθώς αυτά διέρχονται από συσκευές δρομολόγησης. Το NAT αρχικά χρησίμευε για τη διευκόλυνση της αναδρομολόγησης των πακέτων στα δίκτυα IP. Εδώ και πολλά χρόνια όμως αποτελεί ένα πολύτιμο εργαλείο για τη διαχείριση των δημόσιων διευθύνσεων IPv4, εν όψει μάλιστα της εξάντλησής τους.

Υπάρχουν πολλά είδη NAT και για να εξηγήσουμε πώς ακριβώς δουλεύουν οι σχετικές μέθοδοι αντιστοίχισης θα χρειαζόμασταν *τουλάχιστον* ένα εκτενές άρθρο. Στο πλαίσιο του παρόντος αρκεί να πούμε ότι, από τη σκοπιά του Μέσου Παπαδόπουλου (TM), το NAT μάς επιτρέπει να βγάζουμε στο Internet όσες από τις συσκευές μας θέλουμε, με *μία μόνο* δημόσια διεύθυνση IP: αυτή που έχει πάρει ο router μας από τον ISP.

Αναλυτικότερα, οι συσκευές μας συνδέονται –ενσύρματα ή ασύρματα– στον router και, χάρη στον DHCP server του, παίρνουν ωραιότατες αλλά non-routable διευθύνσεις IP, π.χ., της μορφής 192.168.0.0/24 ή της μορφής 10.0.0.0/24 (βλ. περισσότερα εδώ). Οι διευθύνσεις αυτές είναι μια χαρά για ένα τοπικό δίκτυο αλλά *όχι* για το Internet. Ευτυχώς, κάθε φορά που μία συσκευή χρειάζεται να συνδεθεί σε web site ή γενικά σε υπηρεσία του Διαδικτύου, o router αλλάζει τη non-routable διεύθυνση πηγής (source IP) στα headers των σχετικών πακέτων και βάζει στη θέση της εκείνη που έχει πάρει από τον ISP και είναι routable για το Διαδίκτυο (ακριβέστερα: για το δίκτυο “μπροστά” από τον router). Έτσι, τα πακέτα είναι σε θέση να ταξιδεύουν Εκεί Έξω (TM) και μετά βασάνων και κόπων να φτάνουν στους προορισμούς τους. Όταν τώρα αποστέλλεται μια απάντηση από κάποιον ιντερνετικό server, εν είδει πακέτου IP, εκείνος που τη λαμβάνει είναι πάντα ο ακούραστος router μας. Χάρη σε σχετικό πίνακα που τηρεί, ο router ξέρει ότι ο πραγματικός αποδέκτης του πακέτου δεν είναι ο ίδιος αλλά η συσκευή που ξεκίνησε την επικοινωνία με τον server. Αλλάζει, λοιπόν, το δημόσιο IP στο πεδίο “destination IP” στο header του πακέτου, στη θέση του βάζει την “εσωτερική” διεύθυνση IP της συσκευής που είναι υπεύθυνη για όλη αυτή την αναστάτωση, κι αμέσως στέλνει το πακέτο προς τα εκεί που πρέπει.

Τώρα, κατά την αρχική ρύθμιση του pfSense οι κανόνες NAT για τα πακέτα που εξέρχονται από το WAN interface προστίθενται αυτόματα στο firewall ruleset. Δεν συμβαίνει όμως το ίδιο και για το network interface που δημιουργείται αμέσως μετά τη ρύθμιση του OpenVPN client. Το εν λόγω interface εμείς το ονομάσαμε DefiantVPN και για τον ορισμό κανόνων NAT που επιδρούν στα πακέτα που διέρχονται απ’ αυτό δώσαμε Firewall –> NAT –> Outbound –> Manual Outbound NAT rule generation (AON – Advanced Outbound NAT). Ο νέος κανόνας NAT που προσθέσαμε αφορά σε όλα τα πακέτα που εξέρχονται από το DefiantVPN, άσχετα από ποιο μηχάνημα ξεκινούν, ανεξαρτήτως του πρωτοκόλλου στο οποίο αφορούν (TCP, UDP, ICMP κ.ά.), κι ανεξαρτήτως του προορισμού τους. Στο screenshot που ακολουθεί προσέξτε την παράμετρο Address (περιοχή Translation), για την οποία επιλέξαμε την τιμή Interface address: Πρόκειται για τη διεύθυνση IP που αποδίδεται στο DefiantVPN από τον απομακρυσμένο OpenVPN Access Server (και για το δικό μας setup είναι η 172.27.232.2). Αυτή τη διεύθυνση βάζει στο πεδίο “source IP” των εξερχόμενων πακέτων, ο κανόνας NAT που ορίσαμε μόλις.

Ο νέος κανόνας NAT που προσθέσαμε χειροκίνητα στο firewall ruleset του pfSense. Παρουσία του διασφαλίζεται ότι στο πεδίο 'source IP', στο header των πακέτων που εξέρχονται από το DefiantVPN, υπάρχει η διεύθυνση IP που ο Access Server έχει αποδώσει στο προαναφερθέν network interface. Παρόμοιοι κανόνες NAT που αφορούν στο WAN interface είχαν προστεθεί αυτόματα, κατά την αρχική ρύθμιση του pfSense.

Ο νέος κανόνας NAT που προσθέσαμε χειροκίνητα στο firewall ruleset του pfSense. Παρουσία του διασφαλίζεται ότι στο πεδίο “source IP”, στο header των πακέτων που εξέρχονται από το DefiantVPN, υπάρχει η διεύθυνση IP που ο Access Server έχει αποδώσει στο προαναφερθέν network interface. Παρόμοιοι κανόνες NAT που αφορούν στο WAN interface είχαν προστεθεί αυτόματα, κατά την αρχική ρύθμιση του pfSense.

Η σύνδεση με τον Access Server διακόπτεται :/
Μετά τη ρύθμιση του pfSense router ώστε να λειτουργεί ως client για τον OpenVPN Access Server, πιθανώς θα παρατηρήσατε ότι η σύνδεση προς το απομακρυσμένο μηχάνημα έχει μια τάση να διακόπτεται. Αν κάνετε όπως εμείς κι αφήνετε τον OpenVPN client να λειτουργεί αδιάκοπα, είναι *βέβαιο* ότι θα το έχετε παρατηρήσει. Δεν πρόκειται για φαινόμενο που συμβαίνει τυχαία, π.χ., εξαιτίας κάποιου bug. Κάθε άλλο: Αυτή ακριβώς είναι η προκαθορισμένη συμπεριφορά του Access Server, για τα profiles χρηστών με το auto-login απενεργοποιημένο. (Οι χρήστες με τέτοια προφίλ, εκτός από το να κατέχουν το κατάλληλο ιδιωτικό κλειδί και πιστοποιητικό, κατά τη σύνδεσή τους πρέπει να παρέχουν username και password.)

Εξ ορισμού, λοιπόν, ο Access Server διακόπτει τις συνδέσεις των προφίλ χωρίς auto-login κάθε 86.400 δευτερόλεπτα, δηλαδή κάθε 24 ώρες. Ευτυχώς, μπορούμε να αλλάξουμε τη σχετική παράμετρο και να της αποδώσουμε μια πολύ μεγάλη τιμή, ώστε στην πράξη οι αποσυνδέσεις να μην έχουν καμία ευκαιρία να συμβαίνουν. Θέτοντας το χρόνο για την αποσύνδεση, π.χ., στα 31.104.000 δευτερόλεπτα (360 μέρες), είναι βέβαιο ότι πριν ο Access Server προλάβει να διακόψει συνδέσεις θα έχουμε κάνει εμείς κάποιο reboot, π.χ., λόγω κάποιου major upgrade στο pfSense ή λόγω αναβάθμισης του πυρήνα στο λειτουργικό που τρέχει το VPS του Access Server.

Παρατηρώντας το log file του OpenVPN Access Server μέσα από web panel διαχείρισης, εύκολα διαπιστώνουμε ότι ο server αποσυνδέει τον έναν και μοναδικό του client κάθε 24 ώρες. Ο εν λόγω client είναι ο pfSense router μας κι αυτή η κατάσταση με τις αποσυνδέσεις πρέπει να σταματήσει, αφού δημιουργούνται προβλήματα στις συσκευές πίσω από τον router.

Παρατηρώντας το log file του OpenVPN Access Server μέσα από web panel διαχείρισης, εύκολα διαπιστώνουμε ότι ο server αποσυνδέει τον έναν και μοναδικό του client κάθε 24 ώρες. Ο εν λόγω client είναι ο pfSense router μας κι αυτή η κατάσταση με τις αποσυνδέσεις πρέπει να σταματήσει, αφού δημιουργούνται προβλήματα στις συσκευές πίσω από τον router.

Προκειμένου ν’ αλλάξουμε το χρόνο για την αποσύνδεση, συνδεόμαστε στο VPS του OpenVPN Access Server μέσω SSH και πληκτρολογούμε:

sub0@defiant:~$ sudo /usr/local/openvpn_as/scripts/sacli \
--key vpn.server.session_expire --value 31536000 ConfigPut
sub0@defiant:~$ sudo /usr/local/openvpn_as/scripts/sacli start

Η παράμετρος που επηρεάσαμε είναι η vpn.server.session_expire. Παρεμπιπτόντως, όλες οι παράμετροι που καθορίζουν τη συμπεριφορά του OpenVPN Access Server τηρούνται στην SQLite database ονόματι config.db, κάτω από το /usr/local/openvpn_as/etc/db.

Έχοντας συνδεθεί μέσω SSH στο VPS που τρέχει ο OpenVPN Access Server, αλλάζουμε την τιμή αποσύνδεσης για τους χρήστες του Access Server με προφίλ *χωρίς* auto-login. Στο εξής, οι αυτόματες αποσυνδέσεις θα γίνονται κάθε ένα χρόνο. Στο μεταξύ, είναι σχεδόν σίγουρο πως ούτως ή άλλως θα έχουμε επανεκκινήσει το pfSense ή το λειτουργικό του VPS, π.χ., λόγω αναβάθμισης του πυρήνα.

Έχοντας συνδεθεί μέσω SSH στο VPS που τρέχει ο OpenVPN Access Server, αλλάζουμε την τιμή αποσύνδεσης για τους χρήστες του Access Server με προφίλ *χωρίς* auto-login. Στο εξής, οι αυτόματες αποσυνδέσεις θα γίνονται κάθε ένα χρόνο. Στο μεταξύ, είναι σχεδόν σίγουρο πως ούτως ή άλλως θα έχουμε επανεκκινήσει το pfSense ή το λειτουργικό του VPS, π.χ., λόγω αναβάθμισης του πυρήνα.

Επιλεκτική δρομολόγηση μέσω VPN
Η δρομολόγηση της δικτυακής κίνησης μέσω του απομακρυσμένου Access Server συχνά έχει αρνητική επίπτωση στην ταχύτητα. Η επίπτωση αυτή άλλοτε είναι πρακτικά αμελητέα, άλλες φορές όμως δεν περνά απαρατήρητη. Όλα εξαρτώνται από το είδος της διαδικτυακής υπηρεσίας που προσπελαύνουμε. Παράδειγμα: Για τυπικό web browsing, το πιθανότερο είναι να μην αντιλαμβανόμαστε την όποια μείωση στην ταχύτητα. Αν βέβαια ο web server που επισκεπτόμαστε είναι γεωγραφικά κοντά μας ή/και δεν διαθέτει το καλύτερο bandwidth, το να τον προσεγγίζουμε, π.χ., μέσω data center στη Νέα Υόρκη, σίγουρα απέχει από το βέλτιστο — πάντα όσον αφορά στην ταχύτητα. (Ο OpenVPN Access Server που διαχειριζόμαστε κατοικεί σε data center στη Νέα Υόρκη.) Άλλο παράδειγμα: Στο τοπικό μας δίκτυο ίσως έχουμε ένα μηχάνημα το οποίο χρησιμοποιούμε κυρίως για online gaming, οπότε ειδικά αυτό καλό είναι να μη βαίνει έξω μέσω VPN. Μπορεί βέβαια να ισχύει και το αντίστροφο: μέσω Access Server να θέλουμε να βγαίνουν στο Internet συγκεκριμένα μόνο μηχανήματα. Η καλύτερη λύση για σενάρια σαν τα προαναφερθέντα, είναι να προσθέσουμε στο ruleset του firewall κανόνες που θα φροντίζουν για ένα ή περισσότερα από τα ακόλουθα:

  • όταν επισκεπτόμαστε συγκεκριμένα sites να μην τα προσεγγίζουμε μέσω του ISP
  • όταν επισκεπτόμαστε συγκεκριμένα sites να τα προσεγγίζουμε μέσω του Access Server
  • μόνο συγκεκριμένες συσκευές του τοπικού δικτύου να βγαίνουν έξω μέσω του ISP
  • μόνο συγκεκριμένες συσκευές του τοπικού δικτύου να βγαίνουν έξω μέσω του Access Server

Τα προηγούμενα τα πετυχαίνουμε προσθέτοντας τους κατάλληλους κανόνες στο firewall του pfSense, για το network interface που βλέπουν οι πελάτες και βεβαίως με τη σωστή σειρά. Είναι πολύ πιθανό να έχουμε πολλές υπηρεσίες, συσκευές ή sites για τα οποία επιθυμούμε εξαιρέσεις μέσω κανόνων. Ο βέλτιστος τρόπος προκειμένου να τους ορίσουμε και να τους διαχειριζόμαστε είναι με τη βοήθεια των λεγόμενων aliases.

Τα aliases του pfSense
Τα aliases μπορούμε να τα φανταζόμαστε ως λίστες με ένα ή περισσότερα ομοειδή στοιχεία. Αναφερόμενοι σε στοιχεία εννοούμε ports, hosts ή ολόκληρα δίκτυα. Ένα alias, για παράδειγμα, μπορεί να ισούται με τη λίστα {22, 80, 443, 1194}, όπου τα στοιχεία της είναι TCP ports που είναι προσβάσιμα από το Intetnet. Άλλο alias ίσως ταυτίζεται με τη λίστα {192.168.10.5, 192.168.10.95}, όπου τα μηχανήματα με διευθύνσεις 192.168.10.5 και 192.168.10.95 βγαίνουν στον έξω κόσμο πάντα μέσω VPN. Κάποιο άλλο alias μπορεί να ταυτίζεται με τη λίστα {192.168.100.0/24, 192.168.150.0/24}, ώστε να περιγράφει τα δίκτυα για τα οποία η πρόσβαση στο Internet επιτρέπεται μόνο κατά συγκεκριμένα χρονικά διαστήματα μέσα στο εικοσιτετράωρο. Τα aliases με hosts, αντί για IPs επιτρέπεται να έχουν και FQDNs. Έτσι, είναι δυνατόν να διαθέτουμε, π.χ., ένα alias που ισούται με τη λίστα {deltahacker.gr, parabing.com, colder.xyz}, ώστε σε καθένα από αυτά τα sites να φτάνουμε πάντα μέσω του ISP μας κι όχι μέσω απομακρυσμένου VPN server. Στην περίπτωση που σε ένα FQDN αντιστοιχούν περισσότερα από ένα IPs, στη λίστα λαμβάνονται υπόψη όλα.

Σε περίπτωση που σ' ένα alias υπάρχει FQDN στο οποίο αντιστοιχούν περισσότερες από μία διευθύνσεις IP, όπως, π.χ., συμβαίνει με το softpedia.com, στο alias θα είναι σαν να περιλαμβάνονται όλες αυτές οι διευθύνσεις.

Σε περίπτωση που σ’ ένα alias υπάρχει FQDN στο οποίο αντιστοιχούν περισσότερες από μία διευθύνσεις IP, όπως, π.χ., συμβαίνει με το softpedia.com, στο alias θα είναι σαν να περιλαμβάνονται όλες αυτές οι διευθύνσεις.

Το πόσο βολικά είναι τα aliases καταδεικνύεται όταν τα χρησιμοποιούμε σε κανόνες του firewall. Περισσότερα επ’ αυτού θα δούμε σε πολύ λίγο. Προς το παρόν, ας υπογραμμίσουμε την ευκολία που παρέχουν: Χάρη σ’ αυτά, κάθε φορά που ένα ή περισσότερα ports/hosts/δίκτυα πρέπει ν’ αλλάξουν, οι συνεπακόλουθες αλλαγές στα rulesets του firewall ελαχιστοποιούνται. Το μόνο που απαιτείται από μέρους μας είναι να ορίζουμε aliases έχοντας ξεκαθαρισμένο το ρόλο τους. Βοηθά, βεβαίως, να τους δίνουμε και περιγραφικά ονόματα. Περιττό επίσης να σημειώσουμε ότι στα aliases μπορούμε να προσθέτουμε ή να αφαιρούμε μέλη όποτε θέλουμε, και η ισχύς των εμπλεκομένων κανόνων θα επεκτείνεται ή θα περιορίζεται αντιστοίχως. Όμως ας αφήσουμε τη γενική συζήτηση κι ας δούμε δύο παραδείγματα aliases, τα οποία έχουμε ορισμένα στον δικό μας pfSense router.

το πρώτο άρθρο της σχετικής σειράς). Για το static site δεν μας πειράζει και τόσο, όμως δεν βλέπουμε το λόγο να διακινούμε την ηλεκτρονική μας αλληλογραφία μέσω Νέας Υόρκης.

Αφού ορίσαμε το alias ονόματι via_ISP, έμενε να προσθέσουμε έναν σχετικό κανόνα στο ruleset του pfSense firewall — βεβαίως για το κατάλληλο network interface. Περισσότερα επ’ αυτού σε πολύ λίγο.

Μέρος των περιεχομένων του alias ονόματι via_ISP, το οποίο περιλαμβάνει υπηρεσίες και sites στα οποία θέλουμε να φτάνουμε πάντοτε μέσω του ISP μας κι όχι μέσω του απομακρυσμένου OpenVPN Access Server.

Μέρος των περιεχομένων του alias ονόματι via_ISP, το οποίο περιλαμβάνει υπηρεσίες και sites στα οποία θέλουμε να φτάνουμε πάντοτε μέσω του ISP μας κι όχι μέσω του απομακρυσμένου OpenVPN Access Server.

Εφαρμογή 2: Χρήση VPN για συγκεκριμένα hosts
Στο τοπικό μας δίκτυο πίσω από το pfSense, αυτή τη στιγμή υπάρχει ένας δικτυακός εκτυπωτής, ένα tablet, δύο smartphones, δύο laptops, ένα PC με το ProxMox VE, ένα VM με Ubuntu Server σε ρόλο Dropbox node, καθώς κι ένα VM με Ubuntu Desktop που έχει χρέη Bitcoin full node. Μιλάμε, μ’ άλλα λόγια, για εννέα διαφορετικούς clients. Για λόγους που δεν χρειάζεται να παραθέσουμε τώρα, δύο μόνο από τις εννέα αυτές συσκευές έχει νόημα (και είναι επιθυμητό) να βγαίνουν διαρκώς στο Internet μέσω Access Server: το ένα από τα δύο laptops και το ένα από τα δύο smartphones. Ακριβώς γι’ αυτό, λοιπόν, ορίσαμε ένα alias που ονομάσαμε VPNed_hosts και περιλαμβάνει τις δύο διευθύνσεις IP που οι δύο αυτές συσκευές παίρνουν από τον DHCP server του pfSense. (Εννοείται πως έχουμε ήδη μεριμνήσει, μέσα από το web panel του pfSense, ώστε οι υπό συζήτηση συσκευές να παίρνουν πάντοτε τις ίδιες διευθύνσεις IP.)

Είδαμε τα δύο aliases του pfSense box, εξηγήσαμε και το λόγο ύπαρξης καθενός. Στην επόμενη ενότητα παραθέτουμε και τους σχετικούς κανόνες στο firewall του pfSense, ώστε να υλοποιείται η επιθυμητή πολιτική διαχείρισης της δικτυακής κυκλοφορίας.

Το alias ονόματι VPNed_hosts περιλαμβάνει τις διευθύνσεις IP των δύο συσκευών που επιθυμούμε να βγαίνουν στο Internet *πάντοτε* μέσω του απομακρυσμένου OpenVPN Access Server. Όλες οι άλλες συσκευές βγαίνουν απευθείας, δηλαδή παρακάμπτουν το κρυπτογραφημένο τούνελ από το pfSense box έως το VPS του Access Server.

Το alias ονόματι VPNed_hosts περιλαμβάνει τις διευθύνσεις IP των δύο συσκευών που επιθυμούμε να βγαίνουν στο Internet *πάντοτε* μέσω του απομακρυσμένου OpenVPN Access Server. Όλες οι άλλες συσκευές βγαίνουν απευθείας, δηλαδή παρακάμπτουν το κρυπτογραφημένο τούνελ από το pfSense box έως το VPS του Access Server.

Κανόνες στο firewall
Από το web panel του pfSense επιλέγουμε System –> Routing κι εστιάζουμε την προσοχή μας στην καρτέλα Gateways. Μετά την πρώτη εγκατάσταση και ρύθμιση του pfSense υπάρχει μία μόνο προκαθορισμένη πύλη, με όνομα WANGW: Πρόκειται για εκείνη που χρησιμοποιεί το WAN interface του pfSense ώστε οι συσκευές πίσω από τον router να βγαίνουν στο Internet. Αυτή η πύλη οδηγεί απευθείας στον ISP μας. Μετά όμως τη ρύθμιση του client για τον OpenVPN Access Server, στο pfSense διατίθεται και η πύλη με όνομα OVPNDEFIANT_VPNV4 — ή τουλάχιστον αυτό είναι το όνομά της για τη δική μας εγκατάσταση. Η εν λόγω πύλη χρησιμοποιείται από το DefiantVPN interface κι όσες συσκευές τη χρησιμοποιούν δεν βγαίνουν στο Internet απευθείας από τον ISP, αλλά αφού πρώτα περάσουν από το κρυπτογραφημένο τούνελ που ξεκινά από το pfSense και καταλήγει στον Access Server.

Τα δύο gateways του δικού μας pfSense box. Από το WANGW οι πελάτες βγαίνουν απευθείας στο Internet, μέσω του ISP μας. Από το OPENVPNDEFIANT_VPNV4 οι πελάτες βγαίνουν στο Internet από τον OpenVPN Access Server, ταξιδεύοντας μέσα από το κρυπτογραφημένο τούνελ που υφίσταται μεταξύ pfSense box κι απομακρυσμένου VPS.

Τα δύο gateways του δικού μας pfSense box. Από το WANGW οι πελάτες βγαίνουν απευθείας στο Internet, μέσω του ISP μας. Από το OPENVPNDEFIANT_VPNV4 οι πελάτες βγαίνουν στο Internet από τον OpenVPN Access Server, ταξιδεύοντας μέσα από το κρυπτογραφημένο τούνελ που υφίσταται μεταξύ pfSense box κι απομακρυσμένου VPS.

Τις δύο προναφερθείσες πύλες, WANGW και OPENVPNDEFIANT_VPNV4, πρέπει να έχουμε υπόψη κατά τη σύνταξη των κανόνων δρομολόγησης της κίνησης. Τώρα, για την προσθήκη των κανόνων δίνουμε Firewall –> Rules. Οι νέοι κανόνες θα αφορούν στο network interface που έχουν μπροστά τους οι πελάτες του router, αφού ενδιαφερόμαστε για τα πακέτα που εξέρχονται από το τοπικό δίκτυο. Κατά πάσα πιθανότητα μιλάμε για το LAN interface. Υπάρχουν όμως κι άλλες δυνατότητες. Για παράδειγμα, στο δικό μας setup ασχοληθήκαμε με το OPT2 interface, το οποίο αποτελεί bridge των LAN και OPT1. Σε κάθε περίπτωση, στη σελίδα “Firewall: Rules” κάντε κλικ στην καρτέλα του κατάλληλου για την εγκατάστασή σας network interface. Δείτε στα screenshots που ακολουθούν τους κανόνες που ισχύουν για το δικό μας interface (το OPT2), διαβάστε βεβαίως και τις αντίστοιχες περιγραφές.

Ιδού οι τρεις κανόνες του firewall για το OPT2, το network interface που βλέπουν οι πελάτες του pfSense. Η σειρά των κανόνων έχει σημασία, αφού εφαρμόζονται από πάνω προς τα κάτω, ο πρώτος κανόνας που 'ταιριάζει' σε εισερχόμενο πακέτο ενεργοποιείται, ενώ όλοι οι άλλοι από 'κάτω', αν υπάρχουν, αγνοούνται.

Ιδού οι τρεις κανόνες του firewall για το OPT2, το network interface που βλέπουν οι πελάτες του pfSense. Η σειρά των κανόνων έχει σημασία, αφού εφαρμόζονται από πάνω προς τα κάτω, ο πρώτος κανόνας που “ταιριάζει” σε εισερχόμενο πακέτο ενεργοποιείται, ενώ όλοι οι άλλοι από “κάτω”, αν υπάρχουν, αγνοούνται. Έτσι, οι τρεις εικονιζόμενοι κανόνες έχουν τα ακόλουθα αποτελέσματα:

  • αν ένα πακέτο, απ’ όποιον client κι αν προέρχεται, προορίζεται για κάποιον από τους hosts που παρατίθενται στο alias ονόματι via_ISP, τότε στείλε το έξω μέσω του WANGW gateway (δηλαδή όχι μέσω του κρυπτογραφημένου τούνελ) — κι αγνόησε τους κανόνες από κάτω
  • αν ένα πακέτο προέρχεται από κάποιον εκ των clients που παρατίθενται στο alias ονόματι VPNed_hosts, τότε στείλε το έξω μέσω του OVPNDEFIANT_VPNV4 gateway (δηλαδή μέσω του κρυπτογραφημένου τούνελ) — κι αγνόησε τους κανόνες από κάτω
  • αν ένα πακέτο προέρχεται από έναν οποιονδήποτε άλλον client, τότε στείλε το έξω μέσω του WANGW gateway (δηλαδή όχι μέσω του κρυπτογραφημένου τούνελ)
  • Θα μπορούσε κάποιος να ισχυριστεί ότι 1ος κανόνας είναι περιττός και ότι ο 2ος κι ο 3ος θα ήταν αρκετοί. Στην πραγματικότητα όμως η παρουσία του 1ου κανόνα είναι απαραίτητη, ώστε αν κάποιο πακέτο προορίζεται για κάποιον host από το via_ISP να βγαίνει έξω μέσω WANGW ακόμη κι όταν προέρχεται από client της λίστας VPNed_hosts.

Ζουμ στις παραμέτρους του 1ου κανόνα. Προσέξτε την ενότητα Destination, όπου θέσαμε Type = Single host or alias και στη θυρίδα Address πληκτρολογήσαμε το όνομα του alias με τα hosts στα οποία θέλουμε να φτάνουμε μέσω WANGW (via_ISP).

Ζουμ στις παραμέτρους του 1ου κανόνα. Προσέξτε την ενότητα Destination, όπου θέσαμε Type = Single host or alias και στη θυρίδα Address πληκτρολογήσαμε το όνομα του alias με τα hosts στα οποία θέλουμε να φτάνουμε μέσω WANGW (via_ISP).

Λίγο πιο κάτω, στην περιοχή με τα Advanced features του κανόνα, δεν λησμονήσαμε να θέσουμε Gateway = WANGW.

Λίγο πιο κάτω, στην περιοχή με τα Advanced features του κανόνα, δεν λησμονήσαμε να θέσουμε Gateway = WANGW.

Ζουμ στις παραμέτρους του 2ου κανόνα. Αυτή τη φορά εστιάσαμε την προσοχή μας στην ενότητα Source. Θέσαμε και πάλι Type = Single host or alias αλλά στη θυρίδα Address πληκτρολογήσαμε VPNed_hosts, το οποίο είναι το όνομα που έχουμε δώσει στο alias με τα IPs των clients που επιθυμούμε να βγαίνουν στο Internet μέσω του Access Server.

Ζουμ στις παραμέτρους του 2ου κανόνα. Αυτή τη φορά εστιάσαμε την προσοχή μας στην ενότητα Source. Θέσαμε και πάλι Type = Single host or alias αλλά στη θυρίδα Address πληκτρολογήσαμε VPNed_hosts, το οποίο είναι το όνομα που έχουμε δώσει στο alias με τα IPs των clients που επιθυμούμε να βγαίνουν στο Internet μέσω του Access Server.

Στην περιοχή Gateway της ενότητας Advanced features θέσαμε Gateway = OVPNDEFIANT_VPNV4, ώστε οι clients που παρατίθενται στη λίστα VPNed_hosts να περνάνε μέσα από το κρυπτογραφημένο κανάλι που υφίσταται μεταξύ pfSense και OpenVPN Access Server.

Στην περιοχή Gateway της ενότητας Advanced features θέσαμε Gateway = OVPNDEFIANT_VPNV4, ώστε οι clients που παρατίθενται στη λίστα VPNed_hosts να περνάνε μέσα από το κρυπτογραφημένο κανάλι που υφίσταται μεταξύ pfSense και OpenVPN Access Server.

Ο τρίτος και τελευταίος κανόνας αφορά σε πακέτα που δεν προορίζονται σε κάποιον host από τη λίστα via_ISP και ταυτόχρονα δεν προέρχονται από client της λίστας VPNed_hosts. Απλά φροντίζει ώστε όλα αυτά τα πακέτα να περνάνε από το WANGW gateway, δηλαδή όχι μέσα από το κρυπτογραφημένο κανάλι.

Ο τρίτος και τελευταίος κανόνας αφορά σε πακέτα που δεν προορίζονται σε κάποιον host από τη λίστα via_ISP και ταυτόχρονα δεν προέρχονται από client της λίστας VPNed_hosts. Απλά φροντίζει ώστε όλα αυτά τα πακέτα να περνάνε από το WANGW gateway, δηλαδή όχι μέσα από το κρυπτογραφημένο κανάλι.

Έλεγχοι με το mtr
Αφού ορίσουμε τους κανόνες μας για το interface που βλέπουν οι clients του pfSense και τους εφαρμόσουμε, καλό είναι να κάνουμε και δυο-τρεις ελέγχους προκειμένου να βεβαιωθούμε ότι έχουν το επιθυμητό αποτέλεσμα. Ένα βολικό εργαλείο γι’ αυτή τη δουλειά είναι το traceroute (tracert στα Windows). Εναλλακτικά υπάρχει και το mtr, το οποίο συνδυάζει τα traceroute και ping. Τα traceroute (tracert) και mtr δείχνουν τη διαδρομή που κάνουν τα δικτυακά πακέτα από τον υπολογιστή μας έως ότου φτάσουν σε κάποιον άλλον host (στο τοπικό δίκτυο ή στο Internet). Οι έλεγχοι που εμείς κάναμε ήταν με χρήση των tracert και mtr και είχαν ως ακολούθως:

  • tracert από VM με Windows 10, όπου το λειτουργικό έβγαινε στο Internet μέσω WANGW. Επιθυμητό αποτέλεσμα: Τα πακέτα *δεν* περνάνε από το κρυπτογραφημένο τούνελ.
  • mtr από laptop με OS X που έβγαινε στο Internet μέσω OVPNDEFIANT_VPNV4, προς site της λίστας via_ISP. Επιθυμητό αποτέλεσμα: Τα πακέτα *δεν* περνάνε από το κρυπτογραφημένο τούνελ.
  • mtr από το ίδιο laptop με OS X (και πάλι έβγαινε στο Internet μέσω OVPNDEFIANT_VPNV4), προς site *εκτός* της λίστας via_ISP. Επιθυμητό αποτέλεσμα: Τα πακέτα *περνάνε* από το κρυπτογραφημένο τούνελ.

Δείτε στα screenshots που ακολουθούν μερικά στιγμιότυπα των δοκιμών μας.

Από ένα VM με Windows 10 που *δεν* βγαίνει στο Intetnet μέσω του απομακρυσμένου OpenVPN Access Server, κάνουμε ένα tracert προς το eff.org. Το πρώτο hop είναι προς το 192.168.1.1, το οποίο είναι ο WANGW και ταυτίζεται με το LAN interface του modem/router μπροστά από το pfSense. Από εκεί και πέρα, πριν φτάσουμε στο eff.org περνάμε από 10 ενδιάμεσα μηχανήματα στο Internet. Το ότι το πρώτο hop είναι προς το 192.168.1.1 και μετά βγαίνουμε στο Internet, φανερώνει ότι η δρομολόγηση πράγματι δεν γίνεται μέσω του κρυπτογραφημένου τούνελ προς τον Access Server.

Από ένα VM με Windows 10 που *δεν* βγαίνει στο Intetnet μέσω του απομακρυσμένου OpenVPN Access Server, κάνουμε ένα tracert προς το eff.org. Το πρώτο hop είναι προς το 192.168.1.1, το οποίο είναι ο WANGW και ταυτίζεται με το LAN interface του modem/router μπροστά από το pfSense. Από εκεί και πέρα, πριν φτάσουμε στο eff.org περνάμε από 10 ενδιάμεσα μηχανήματα στο Internet. Το ότι το πρώτο hop είναι προς το 192.168.1.1 και μετά βγαίνουμε στο Internet, φανερώνει ότι η δρομολόγηση πράγματι δεν γίνεται μέσω του κρυπτογραφημένου τούνελ προς τον Access Server.

Τρέχουμε το mtr σε ένα laptop με OS X το οποίο βγαίνει στο Intetnet μέσω του απομακρυσμένου Access Server, αλλά επιχειρούμε να χαρτογραφήσουμε τη διαδρομή προς έναν host από τη λίστα via_ISP. Διαπιστώνουμε ότι τα πακέτα που στέλνει το mtr δεν περνάνε μέσα από το κρυπτογραφημένο τούνελ -- κι αυτή ακριβώς είναι επιθυμητή συμπεριφορά.

Τρέχουμε το mtr σε ένα laptop με OS X το οποίο βγαίνει στο Intetnet μέσω του απομακρυσμένου Access Server, αλλά επιχειρούμε να χαρτογραφήσουμε τη διαδρομή προς έναν host από τη λίστα via_ISP. Διαπιστώνουμε ότι τα πακέτα που στέλνει το mtr δεν περνάνε μέσα από το κρυπτογραφημένο τούνελ — κι αυτή ακριβώς είναι επιθυμητή συμπεριφορά.

Τρέχουμε ξανά το mtr στο ίδιο laptop με OS X, το οποίο εξακολουθεί να βγαίνει στο Intetnet μέσω του απομακρυσμένου Access Server. Τώρα όμως επιχειρούμε να χαρτογραφήσουμε τη διαδρομή προς έναν host *εκτός* της λίστας via_ISP. Παρατηρούμε ότι το πρώτο hop είναι προς το 172.27.232.1, δηλαδή προς τον gateway του DefiantVPN. Αυτό φανερώνει ότι τα πακέτα που στέλνει το mtr ταξιδεύουν μέσα από το κρυπτογραφημένο τούνελ.

Τρέχουμε ξανά το mtr στο ίδιο laptop με OS X, το οποίο εξακολουθεί να βγαίνει στο Intetnet μέσω του απομακρυσμένου Access Server. Τώρα όμως επιχειρούμε να χαρτογραφήσουμε τη διαδρομή προς έναν host *εκτός* της λίστας via_ISP. Παρατηρούμε ότι το πρώτο hop είναι προς το 172.27.232.1, δηλαδή προς τον gateway του DefiantVPN. Αυτό φανερώνει ότι τα πακέτα που στέλνει το mtr ταξιδεύουν μέσα από το κρυπτογραφημένο τούνελ.

Δοκιμαστικά packet captures
Θα ήταν διαφωτιστικό αν είχαμε μια εικόνα για το τι βλέπει ο ISP μας όταν *δεν* χρησιμοποιούμε VPN, αλλά και τι βλέπει όταν δρομολογούμε τη δικτυακή μας κίνηση *μέσω* VPN.

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

Τι μπορούμε λοιπόν να κάνουμε, αν επιθυμούμε ν’ αποκτήσουμε μια εικόνα παρόμοια μ’ εκείνη που έχει ο ISP μας; Μια ιδέα είναι το packet capture της δικτυακής μας κίνησης, αλλά στο επίπεδο του pfSense. Πιο συγκεκριμένα, προτείνουμε δύο captures: ένα όταν έχουμε δικτυακή κίνηση που δεν δρομολογείται μέσω Access Server, βεβαίως κι άλλο ένα όταν έχουμε δικτυακή κίνηση που δρομολογείται μέσω Access Server. Θα πάρουμε έτσι δύο διαφορετικά αρχεία και, στη συνέχεια, με την ησυχία μας θα επιχειρήσουμε μια κάποια ανάλυση, καταφεύγοντας σε εργαλεία όπως το tcpdump ή το Wireshark. Δείτε στα screenshots που ακολουθούν πώς πετυχαίνουμε το packet capture με χρήση της σχετικής δυνατότητας που παρέχει το ίδιο το pfSense.

Packet Capture εμφανίζεται το λακωνικό μήνυμα ‘Packet Capture is running.’. Όταν αοφασίσουμε να το σταματήσουμε, απλά θα κάνουμε ένα κλικ στο κουμπάκι Stop.” href=”http://deltahacker.gr/wp-content/uploads/2015/10/08 pcap 02.jpg” rel=”lightbox[ASlife]”>Όση ώρα λαμβάνει χώρα ένα packet capture, στο κάτω μέρος της σελίδας Diagnostics --> Packet Capture εμφανίζεται το λακωνικό μήνυμα ‘Packet Capture is running.’. Όταν αοφασίσουμε να το σταματήσουμε, απλά θα κάνουμε ένα κλικ στο κουμπάκι Stop.” width=”596″ align=”middle” border=”0″ /></a></p>
<p><em>Όση ώρα λαμβάνει χώρα ένα packet capture, στο κάτω μέρος της σελίδας Diagnostics –> Packet Capture εμφανίζεται το λακωνικό μήνυμα “Packet Capture is running.”. Όταν αοφασίσουμε να το σταματήσουμε, απλά θα κάνουμε ένα κλικ στο κουμπάκι Stop.</em></p>
<p><a title=Αφού σταματήσουμε ένα packet capture, αναλόγως του όγκου των δεδομένων που καταγράφηκαν ίσως χρειαστεί να περιμένουμε μερικά λεπτά. Τελικά, με κλικ στο κουμπί Download Capture θα αποθηκεύσουμε στον υπολογιστή μας ένα αρχείο με κατάληξη .cap, το οποίο θα περιμβάνει όλα τα δικτυακά πακέτα που αποθηκεύτηκαν κατά το προηγούμενο session.

Αφού σταματήσουμε ένα packet capture, αναλόγως του όγκου των δεδομένων που καταγράφηκαν ίσως χρειαστεί να περιμένουμε μερικά λεπτά. Τελικά, με κλικ στο κουμπί Download Capture θα αποθηκεύσουμε στον υπολογιστή μας ένα αρχείο με κατάληξη .cap, το οποίο θα περιμβάνει όλα τα δικτυακά πακέτα που αποθηκεύτηκαν κατά το προηγούμενο session.

Εξέταση/ανάλυση των packet captures
Μετά τα packet captures, τα αρχεία .cap που έχουμε στη διάθεσή μας μπορούμε να τα αναλύσουμε με ένα εργαλείο σαν το tcpdump ή με μια εφαρμογή όπως το Wireshark. Για το packet analysis γενικότερα διαβάστε τα σχετικά άρθρα που δημοσιεύονται στα τεύχη 019 και 020 του deltaHacker. Σ’ αυτά θα βρείτε και συγκεκριμένα παραδείγματα ανάλυσης. Στα screenshots που ακολουθούν βλέπουμε μερικά πρώτα συμπεράσματα που προέκυψαν άμεσα με τη βοήθεια του Wireshark, μετά από δύο packet captures που κάναμε στο δικό μας pfSense box.

Έχουμε φορτώσει στο Wireshark το αρχείο ονόματι packetcapture0.cap, το οποίο δημιουργήθηκε όταν κανένας client δεν χρησιμοποιούσε τον απομακρυσμένο OpenVPN Access Server. Πολύ γρήγορα διαπιστώνουμε ότι οι δραστηριότητες των χρηστών αποκαλύπτονται εύκολα. Στο στιγμιότυπο διακρίνουμε μέρος της επικοινωνίας μεταξύ του router (pfsense.colder.xyz) και του ruv.is -- Κύριος οίδε γιατί!

Έχουμε φορτώσει στο Wireshark το αρχείο ονόματι packetcapture0.cap, το οποίο δημιουργήθηκε όταν κανένας client δεν χρησιμοποιούσε τον απομακρυσμένο OpenVPN Access Server. Πολύ γρήγορα διαπιστώνουμε ότι οι δραστηριότητες των χρηστών αποκαλύπτονται εύκολα. Στο στιγμιότυπο διακρίνουμε μέρος της επικοινωνίας μεταξύ του router (pfsense.colder.xyz) και του ruv.is — Κύριος οίδε γιατί!

Ιδού μερικές από τις συνδέσεις που έλαβαν χώρα μεταξύ του pfSense router και απομακρυσμένων hosts. (Κάποιος έχει αρχίσει να παίζει με το Bitcoin ή είναι η ιδέα μας;)

Ιδού μερικές από τις συνδέσεις που έλαβαν χώρα μεταξύ του pfSense router και απομακρυσμένων hosts. (Κάποιος έχει αρχίσει να παίζει με το Bitcoin ή είναι η ιδέα μας;)

Μερικές από τις διευθύνσεις IP και τα αντίστοιχα fully qualified domain names των ιντερνετικών hosts, με τους οποίους επικοινώνησε ο router μας κατά τη διάρκεια του packet capture. Σ' αυτό το μέρος της λίστας δεν φαίνεται να υπάρχει τίποτε άτακτο. Για λίγο πιο πάνω ή για λίγο πιο κάτω, δεν βάζουμε το χέρι μας στη φωτιά.

Μερικές από τις διευθύνσεις IP και τα αντίστοιχα fully qualified domain names των ιντερνετικών hosts, με τους οποίους επικοινώνησε ο router μας κατά τη διάρκεια του packet capture. Σ’ αυτό το μέρος της λίστας δεν φαίνεται να υπάρχει τίποτε άτακτο. Για λίγο πιο πάνω ή για λίγο πιο κάτω, δεν βάζουμε το χέρι μας στη φωτιά.

Εδώ έχουμε ανοίξει το αρχείο packetcapture1.cap, το οποίο δημιουργήθηκε όταν στο τοπικό δίκτυο λειτουργούσαν μόνο clients τους οποίους ο router έβγαζε έξω αποκλειστικά μέσω Access Server. Παρατηρούμε ότι υπάρχει έντονη επικοινωνία μεταξύ pfsense.colder.xyz και defiant.gr. Παρεμπιπτόντως, αυτό το τελευταίο είναι το FQDN του VPS στο οποίο λειτουργεί ο VPN server. Το πρωτόκολλο επικοινωνίας μεταξύ των δύο μηχανημάτων είναι αναγνωρίσιμο (βλ. στήλη Protocol), ωστόσο το περιεχόμενο της επικοινωνίας είναι ισχυρά κρυπτογραφημένο και καμία άλλη χρήσιμη πληροφορία δεν μπορεί να προκύψει.

Εδώ έχουμε ανοίξει το αρχείο packetcapture1.cap, το οποίο δημιουργήθηκε όταν στο τοπικό δίκτυο λειτουργούσαν μόνο clients τους οποίους ο router έβγαζε έξω αποκλειστικά μέσω Access Server. Παρατηρούμε ότι υπάρχει έντονη επικοινωνία μεταξύ pfsense.colder.xyz και defiant.gr. Παρεμπιπτόντως, αυτό το τελευταίο είναι το FQDN του VPS στο οποίο λειτουργεί ο VPN server. Το πρωτόκολλο επικοινωνίας μεταξύ των δύο μηχανημάτων είναι αναγνωρίσιμο (βλ. στήλη Protocol), ωστόσο το περιεχόμενο της επικοινωνίας είναι ισχυρά κρυπτογραφημένο και καμία άλλη χρήσιμη πληροφορία δεν μπορεί να προκύψει.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων