Στο άρθρο περί δημιουργίας του δικού μας caching name server, φτάσαμε στο σημείο όπου η υπηρεσία είναι έτοιμη και λειτουργεί. Κάναμε και μερικές δοκιμές, ώστε να δούμε στην πράξη αν και πόσο ωφελούμαστε. Είναι ώρα να συζητήσουμε τους διάφορους τρόπους κατά τους οποίους τα μηχανήματα του τοπικού μας δικτύου ενημερώνονται για την παρουσία του ολοκαίνουργιου name server.

Αν χρησιμοποιείτε τον ενσωματωμένο resolver του DSL router σας, παραμερίζοντάς τον για χάρη του νέου που μόλις φτιάξαμε είναι σχεδόν βέβαιο ότι οι δικτυακές επιδόσεις των συσκευών σας θα βελτιωθούν. Ακόμη κι αν έχετε κάποιον ικανό name server στο τοπικό δίκτυο, όπως, π.χ., είναι το Unbound του pfSense, πάντα θα υπάρχουν σενάρια κατά τα οποία ένα ή περισσότερα μηχανήματα του LAN θα ‘ναι καλύτερα να χρησιμοποιούν τον καινούργιο name server. Γενικά, αυτό που μας ενδιαφέρει στο παρόν άρθρο είναι οι διάφοροι τρόποι κατά τους οποίους μερικά ή ακόμη κι όλα τα μηχανήματα ενός τοπικού δικτύου αλλάζουν name server, για χάρη εκείνου που φτιάξαμε.

Αυτόματη ενημέρωση, από το κέντρο

Εκτός ελαχίστων εξαιρέσεων, το πιθανότερο είναι πως στο τοπικό σας δίκτυο υπάρχει τουλάχιστον ένας DHCP server, π.χ., αυτός του DSL router ή του wireless access point, ώστε οι παράμετροι δικτύωσης (IP, subnet mask, gateway κ.ά.) των clients να παίρνουν τιμές αυτόματα. Από τη στιγμή λοιπόν που έχουμε έτοιμο τον name server μας και λειτουργεί κανονικά, ίσως θελήσουμε να ρυθμίσουμε και τον router του τοπικού δικτύου ώστε να ενημερώνει τους πελάτες για την παρουσία του server. Έως αυτή τη στιγμή γινόταν χρήση των name servers του ISP ή εκείνων κάποιου άλλου provider (π.χ., OpenDNS, Google). Αυτή η κατάσταση είναι ώρα ν’ αλλάξει. Τώρα, το πώς ακριβώς ρυθμίζεται ο router διαφέρει από μάρκα σε μάρκα – ακόμη κι από μοντέλο σε μοντέλο της ίδιας μάρκας. Η γενική ιδέα είναι ότι συνδεόμαστε στο web panel του router, μεταβαίνουμε στη σελίδα που αφορά στο LAN και κάπου εκεί ζητάμε να μη λαμβάνονται πληροφορίες DNS από τον ISP αλλά στους πελάτες να γνωστοποιείται ο name server που εμείς υποδεικνύουμε.

Τροποποίηση της συμπεριφοράς ενός τυπικού ADSL router.Τροποποίηση της συμπεριφοράς ενός τυπικού ADSL router. Στους πελάτες μοιράζονται αυτόματα διευθύνσεις IP μεταξύ των 192.168.1.100 και 192.168.1.149 συμπεριλαμβανομένων (1). Ο συγκεκριμένος router αρχικά χρησιμοποιούσε τους name servers που έπαιρνε από τον ISP, γυρίσαμε όμως τη σχετική παράμετρο στο “Manually” (2) και πληκτρολογήσαμε τις διευθύνσεις IP του δικού μας name server (192.168.1.5, primary), καθώς κι ενός της OpenDNS (208.67.222.222, secondary). Αν παρ’ ελπίδα ο name server μας πέσει (λέμε τώρα), τότε αυτομάτως θα επιστρατευτεί ο άλλος.

Χειροκίνητη ενημέρωση

Όλα –ή έστω κάποια– από τα μηχανήματα ενός LAN είναι πιθανό να μην παίρνουν τις δικτυακές παραμέτρους από τον DHCP server, αλλά να διαθέτουν το λεγόμενο static networking configuration. Θεωρούμε ότι, από τη στιγμή που γι’ αυτό το configuration υπεύθυνοι είμαστε εμείς οι ίδιοι, δεν θα είναι καθόλου δύσκολο να αλλάξουμε τις ρυθμίσεις DNS ώστε να λαμβάνεται υπόψη ο καινούργιος name server.

Να σημειώσουμε πάντως ότι η σύγχρονη τάση θέλει όλους τους clients μέσα σ’ ένα LAN να παίρνουν τις ρυθμίσεις δικτύωσης δυναμικά και κεντρικά, από τον DHCP server (π.χ., του router). Δυναμικό configuration χρησιμοποιούν ακόμη και οι συσκευές που για τον οποιονδήποτε λόγο χρειάζονται στατική διεύθυνση IP. Απλά τα εν λόγω μηχανήματα παίρνουν πάντα το ίδιο IP, με βάση το MAC address της ασύρματης ή της ενσύρματης κάρτας δικτύου μέσω της οποίας συμμετέχουν στο δίκτυο. Σε ένα τέτοιο setup διαφορετικά μηχανήματα είναι πιθανόν να μαθαίνουν για διαφορετικούς name servers. Περισσότερα επ’ αυτού συζητάμε στην τελευταία ενότητα του παρόντος άρθρου.

Κάποια μηχανήματα εξάλλου ίσως παίρνουν όλες τις παραμέτρους δικτύωσης δυναμικά, εκτός από τον name server τους που έχει οριστεί χειροκίνητα. Ως ένα παράδειγμα δείτε το ακόλουθο screenshot, στο οποίο φροντίζουμε ώστε ένα μηχάνημα με Windows 10 να χρησιμοποιεί τον name server μας.

Παράδειγμα τροποποίησης των παραμέτρων δικτύωσης ενός μηχανήματος με Windows 10, ώστε να χρησιμοποιεί τον ολοκαίνουργιο name server με IP το 10.0.0.5.Παράδειγμα τροποποίησης των παραμέτρων δικτύωσης ενός μηχανήματος με Windows 10, ώστε να χρησιμοποιεί τον ολοκαίνουργιο name server με IP το 10.0.0.5. Παρατηρήστε ότι οι παράμετροι IP address, Subnet mask και Default gateway είναι δυνατόν να παίρνουν τιμές αυτόματα (από τον DHCP server), αλλά το DNS να ορίζεται χειροκίνητα.

Το Linux, ο NetworkManager και το DNS

Σε αντίθεση με ό,τι συνέβαινε παλαιότερα με όλες τις διανομές Linux, σε αρκετές σύγχρονες που προορίζονται για χρήση desktop (κι όχι μόνο) τα θέματα δικτύωσης διευθετούνται αυτόματα. Λίγα χρόνια πριν, παραμέτρους όπως διεύθυνση IP, subnet mask, DNS, router κ.ο.κ., στις διανομές Linux τις ορίζαμε μόνοι μας τροποποιώντας ένα ή δύο αρχεία απλού κειμένου. Είχαμε βέβαια και τη δυνατότητα για dynamic configuration, ωστόσο και η ίδια η επιλογή μεταξύ dynamic και static configuration ήταν επίσης δική μας. Σήμερα είναι πράγματι εφικτό (ή πιθανό) να εργαζόμαστε παρομοίως, υπάρχει όμως μια ισχυρή τάση προς τον αυτοματισμό. Έτσι, αν δεν σκοπεύουμε να απενεργοποιήσουμε τη σχετική υπηρεσία αυτόματης ρύθμισης δικτύωσης στη διανομή μας, καλό είναι να γνωρίζουμε το πώς λειτουργεί και, κυρίως, πώς τροποποιούμε τη συμπεριφορά της.

Μια δημοφιλής υπηρεσία αυτόματης διευθέτησης θεμάτων δικτύωσης παρέχεται από τον NetworkManager. Η ανάπτυξή του ξεκίνησε το 2004 από τη Red Hat και κάποια στιγμή βρέθηκε υπό την αιγίδα του GNOME Project. Ο NetworkManager σχεδιάστηκε ώστε να διευκολύνονται οι κάτοχοι laptop με Linux, καθώς μεταβαίνουν από ασύρματο δίκτυο σε ασύρματο δίκτυο. Χειρίζεται επιπλέον κι ενσύρματες συνδέσεις, τις οποίες μάλιστα προτιμά. Στη σειρά προτίμησης ακολουθούν οι ασύρματες με SSID στο οποίο έχουμε συνδεθεί ξανά κατά το παρελθόν, και μετά οι ασύρματες με SSID στο οποίο δεν έχουμε συνδεθεί ξανά κατά το παρελθόν. Αξίζει να υπογραμμίσουμε ότι ο NetworkManager κάνει ό,τι μπορεί ώστε η δικτυακή μας σύνδεση να μη διακόπτεται – ή τουλάχιστον να μην το αντιλαμβανόμαστε: Όχι μόνον όταν αλλάζει το ασύρματο δίκτυο, αλλά ακόμη κι όταν αφήνουμε μια ενσύρματη σύνδεση, π.χ., επειδή βγάλαμε το καλώδιο Ethernet από το laptop αλλά στο χώρο υπάρχει ένα προτιμώμενο ασύρματο δίκτυο.

Από αρχιτεκτονικής σκοπιάς ο NetworkManager αποτελείται από δύο κύρια μέρη:

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

Σε διανομές desktop όπως το Ubuntu, το openSUSE, το elementary OS κ.ά., μαζί με την υπηρεσία του NetworkManager έχουμε και front-ends για το αντίστοιχο περιβάλλον γραφικών. Δείτε στα ακόλουθα screenshots πώς τροποποιούμε τη συμπεριφορά του NetworkManager σε ένα σύστημα Linux με openSUSE 13.2, καθώς και σε ένα με Ubuntu 15.04. Σε κάθε περίπτωση, αυτό που μας ενδιαφέρει είναι να επιστρατεύεται ο δικός μας name server.

Από το YaST, το πολυεργαλείο διαχείρισης συστήματος του openSUSE, βλέπουμε ότι για τη δικτύωση παρέχονται δύο μέθοδοι αυτόματης διευθέτησης: μέσω του NetworkManager ή μέσω του Wicked Service.Από το YaST, το πολυεργαλείο διαχείρισης συστήματος του openSUSE, βλέπουμε ότι για τη δικτύωση παρέχονται δύο μέθοδοι αυτόματης διευθέτησης: μέσω του NetworkManager ή μέσω του Wicked Service.

Ο NetworkManager αποδεικνύεται ιδιαίτερα βολικός όταν έχουμε laptop, το οποίο παίρνουμε μαζί μας όπου πηγαίνουμε και συνεπώς συμμετέχει σε πολλά δίκτυα. Ο NetworkManager αποδεικνύεται ιδιαίτερα βολικός όταν έχουμε laptop, το οποίο παίρνουμε μαζί μας όπου πηγαίνουμε και συνεπώς συμμετέχει σε πολλά δίκτυα. Επιλέγοντας στο openSUSE το NetworkManager Service, ο έλεγχος της δικτύωσης παύει να γίνεται μέσω του YaST κι αντ’ αυτού καταφεύγουμε στο κατάλληλο front-end γραφικών για τον NetworkManager. Στο συγκεκριμένο παράδειγμα τρέχουμε την εκδοχή GNOME του openSUSE και στο front-end του NetworkManager φτάνουμε από την περιοχή με τα εικονίδια ελέγχου, πάνω δεξιά. Εναλλακτικά, αρκεί ένα κλικ στο εικονίδιο Network, του παραθύρου All Settings.

Οι ρυθμίσεις δικτύωσης του wired interface (η μοναδική κάρτα Ethernet του συστήματός μας), όπως φαίνονται μέσα από το applet του NetworkManager.Οι ρυθμίσεις δικτύωσης του wired interface (η μοναδική κάρτα Ethernet του συστήματός μας), όπως φαίνονται μέσα από το applet του NetworkManager. Ο name server που χρησιμοποιείται είναι ο 10.0.0.1 και είναι αυτός του (φτηνιάρικου) router μπροστά από το μηχάνημα. Εμείς φυσικά θέλουμε τον name server που μόλις στήσαμε, ο οποίος βρίσκεται στο Ubuntu Server box, με IP το 10.0.0.5. Κάνουμε λοιπόν την επέμβασή μας, ξεκινώντας με ένα κλικ στο σχετικό εικονίδιο.

Στις ρυθμίσεις που αφορούν στη δικτύωση IPv4, παρατηρήστε ότι αφήνουμε τη διευθυνσιοδότηση να γίνεται αυτόματα (Addresses = Automatic (DHCP)). Για το DNS όμως φροντίζουμε ώστε να ισχύει Automatic = OFF.Στις ρυθμίσεις που αφορούν στη δικτύωση IPv4, παρατηρήστε ότι αφήνουμε τη διευθυνσιοδότηση να γίνεται αυτόματα (Addresses = Automatic (DHCP)). Για το DNS όμως φροντίζουμε ώστε να ισχύει Automatic = OFF. Στη γραμμή ονόματι Server, από κάτω, πληκτρολογούμε τη διεύθυνση IP του επιθυμητού name server (10.0.0.5 για το παράδειγμά μας). Επικυρώνουμε τις αλλαγές με ένα κλικ στο κουμπί Apply, κάτω δεξιά. Προκειμένου να βεβαιωθούμε ότι οι αλλαγές έχουν ληφθεί υπόψη, αρκεί να επανεκκινήσουμε τον NetworkManager. Για παράδειγμα, σε ένα παράθυρο τερματικού δίνουμε sudo service NetworkManager restart.

Το ωραιότατο openSUSE μας χρησιμοποιεί τον ωραιότατο name server μας, στο 10.0.0.5. Μερικές δοκιμές με το dig το επιβεβαιώνουν.Το ωραιότατο openSUSE μας χρησιμοποιεί τον ωραιότατο name server μας, στο 10.0.0.5. Μερικές δοκιμές με το dig το επιβεβαιώνουν. αρχείο

Ανοίγοντας το applet του NetworkManager στο Ubuntu, βλέπουμε ότι εξ ορισμού η δικτύωση ρυθμίζεται αυτόματα.Ανοίγοντας το applet του NetworkManager στο Ubuntu, βλέπουμε ότι εξ ορισμού η δικτύωση ρυθμίζεται αυτόματα (Method = automatic (DHCP)). Με μια ματιά στο αρχείο /etc/resolv.conf, εξάλλου, διαπιστώνουμε ότι δεν επιστρατεύεται κάποιος name server από το τοπικό δίκτυο – ούτε καν αυτός του router (1). Αντίθετα, φαίνεται ότι στο σύστημα τρέχει ένας name server κι ο NetworkManager φροντίζει ώστε αυτός να είναι ο προκαθορισμένος. Παρατηρώντας την έξοδο του netstat επιβεβαιώνουμε την υποψία μας: ο τοπικός name server είναι το Dnsmasq (2). Πρόκειται για έναν μικρό κι ελαφρύ forwarder κι αυτή η προσέγγιση του Ubuntu είναι εξαιρετικά βολική, υπό την έννοια ότι το σύστημα διαθέτει όσο πιο κοντά του γίνεται έναν ικανότατο caching name server.

Παρά το γεγονός ότι το Ubuntu χρησιμοποιεί το τοπικό Dnsmasq, ο δικός μας name server μπορεί, αν φυσικά το θέλουμε, να μπει κι εκείνος στο παιχνίδι.Παρά το γεγονός ότι το Ubuntu χρησιμοποιεί το τοπικό Dnsmasq, ο δικός μας name server μπορεί, αν φυσικά το θέλουμε, να μπει κι εκείνος στο παιχνίδι. Για την ακρίβεια, σε περίπτωση που δεν εργαζόμαστε σε κάποιο laptop αλλά σ’ έναν υπολογιστή που μένει στο ίδιο δίκτυο, τότε ο name server μας είναι δυνατόν να ‘ναι αυτός στον οποίο θα προωθεί τα αιτήματα λειτουργικού κι εφαρμογών το Dnsmasq. Προς τούτο, ανοίγουμε το applet του NetworkManager και τροποποιούμε τις ρυθμίσεις του network interface που μας ενδιαφέρει (στο παράδειγμά μας είναι ένα Ethernet interface κι ονομάζεται “Wired connection 1”). Στην καρτέλα IPv4 Settings του νέου παραθύρου που εμφανίζεται, αν η διευθυνσιοδότηση θέλουμε να συνεχίσει να ‘ναι αυτοματοποιημένη τότε φροντίζουμε ώστε να ισχύει Method = Automatic (DHCP) addresses only (1). Στη θυρίδα DNS servers, όμως, λίγο πιο κάτω, πληκτρολογούμε τη διεύθυνση IP του επιθυμητού name server (2). Επικυρώνουμε την αλλαγή με ένα κλικ στο κουμπάκι Save, κάτω δεξιά στο παράθυρο.

Μετά τη μικροαλλαγή στη συμπεριφορά του NetworkManager, ανοίγουμε ένα παράθυρο τερματικού και κάνουμε μερικές δοκιμές.Μετά τη μικροαλλαγή στη συμπεριφορά του NetworkManager, ανοίγουμε ένα παράθυρο τερματικού και κάνουμε μερικές δοκιμές. Η αλλαγή περί DNS που μόλις πραγματοποιήσαμε δεν αντικατοπτρίζεται στο /etc/resolv.conf, όπως εύκολα διαπιστώνουμε γράφοντας cat /etc/resolv.conf (1). Αυτό είναι αναμενόμενο, αφού ο name server που καθορίσαμε είναι αυτός που θα χρησιμοποιεί σε λίγο το Dnsmasq. Ορίσαμε, μ’ άλλα λόγια, τον upstream server του Dnsmasq. Πληκτρολογώντας sudo service NetworkManager status παρατηρούμε ότι προς το παρόν ο upstream server είναι ο 10.0.0.1 – κι αυτός είναι ο router του τοπικού μας δικτύου (2). Επανεκκινούμε τον NetworkManager με ένα sudo service NetworkManager restart κι ελέγχουμε και πάλι τι ισχύει, δίνοντας ξανά sudo service NetworkManager status. Αυτή τη φορά βλέπουμε ότι ο upstream server είναι ο 10.0.0.5 – κι αυτός είναι ο name server μας (3).

Το Ubuntu Server κι ο δικός του name server

Το Ubuntu Server box, στο οποίο εργαστήκαμε στο προηγούμενο άρθρο κι εγκαταστήσαμε το BIND, λαμβάνει αυτομάτως τις παραμέτρους δικτύωσης από τον DHCP του τοπικού δικτύου. Αυτό σημαίνει ότι ο name server που χρησιμοποιεί για το resolving υποδεικνύεται εξωτερικά και συνεπώς παρακάμπτεται η τοπική εγκατάσταση του BIND. Δείτε, π.χ., τι ισχύει στο μηχάνημα των δοκιμών μας:

cat /etc/resolv.conf

Έξοδος:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.1

Το σύστημα και οι εφαρμογές εξυπηρετούνται από τον 10.0.0.1, ο οποίος υπεδείχθη από τον DHCP του τοπικού δικτύου. Αν θέλουμε να εξυπηρετούνται από το BIND, τότε πριν από τον προαναφερθέντα name server πρέπει να βρίσκεται ο 127.0.0.1. Βλέπουμε πάντως ότι το αρχείο /etc/resolv.conf δεν έχει νόημα να το τροποποιήσουμε με το χέρι αφού παράγεται δυναμικά. Μάλιστα κατά το επόμενο boot θα αλλάξει, οπότε η όποια τροποποίηση έχουμε κάνει θα χαθεί. Η δυναμική παραγωγή του /etc/resolv.conf είναι ευθύνη της υπηρεσίας ονόματι resolvconf και για τη συγκρότησή του χρησιμοποιούνται τα αρχεία απλού κειμένου ονόματι head και base, μέσα στον κατάλογο /etc/resolvconf/resolv.conf.d. Δείτε τα περιεχόμενα του head:

cat /etc/resolvconf/resolv.conf.d/head 

Έξοδος:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Περιέχει το ψαρωτικό μήνυμα που είδαμε προηγουμένως κι αποτελεί την αρχή του /etc/resolv.conf. Ε, αν στο τέλος του head προσθέσουμε το nameserver 127.0.0.1, τότε ανεξαρτήτως του name server που υποδεικνύεται εξωτερικά ο πρώτος που θα χρησιμοποιείται από σύστημα κι εφαρμογές θα είναι ο 127.0.0.1, δηλαδή η τοπική εγκατάσταση του BIND. Ας προσθέσουμε τη γραμμή:

sudo su
echo "nameserver 127.0.0.1" >> /etc/resolvconf/resolv.conf.d/head
exit

Ωραία. Στο /etc/resolv.conf δεν έχουν περάσει οι αλλαγές και για να συμβεί κι αυτό αρκεί να επανεκκινήσουμε την υπηρεσία resolvconf:

sudo service resolvconf restart
cat /etc/resolv.conf

Έξοδος:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 10.0.0.1

Πάρα πολύ ωραία. Ας κάνουμε και μια δοκιμή με το dig:

dig isafjordur.is

Έξοδος:

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> isafjordur.is
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59452
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;isafjordur.is.         IN  A

;; Query time: 22 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 03 14:57:06 EEST 2015
;; MSG SIZE  rcvd: 42

Παρατηρήστε τη γραμμή που ξεκινά μ’ αυτό το SERVER: απαντά ο 127.0.0.1 – κι αυτό είναι ό,τι ακριβώς θέλουμε.

Το pfSense, οι name servers του κι ο DHCP

Το pfSense είναι ένα από τα αγαπημένα μας λειτουργικά συστήματα για χρήση router/firewall. O name server που χρησιμοποιούσε το pfSense έως την έκδοση 2.2 ήταν το Dnsmasq και στο μενού Services του web panel αναγραφόταν ως “DNS Forwarder”. Από την έκδοση 2.2 κι έπειτα υπάρχει κι άλλος ένας resolver στο pfSense: Πρόκειται για το Unbound, στο μενού Services αναφέρεται ως “DNS Resolver”, και στις νέες εγκαταστάσεις του λειτουργικού είναι ενεργοποιημένος εξ ορισμού. (Το Dnsmasq εξακολουθεί να ‘ναι παρόν, αλλά δεν είναι ενεργό.)

Το Unbound έχει τη δυνατότητα να λειτουργεί είτε ως recursive είτε ως forwarding name server. Είναι περισσότερο από ικανό για να εξυπηρετεί το τοπικό σας δίκτυο, όσοι κι αν είναι οι ενεργοί πελάτες. Πάντως σε κάποιες περιπτώσεις είναι πιθανό να θέλετε κάποιον ξεχωριστό name server για ένα σύνολο μηχανημάτων – κι αυτός ο ξεχωριστός name server κάλλιστα μπορεί να είναι εκείνο το Ubuntu Server box με το BIND. Χάρη στην ευελιξία του DHCP server που διαθέτει το pfSense, ο καθορισμός name server γίνεται είτε κατά πελάτη είτε κατά network interface. Σίγουρα για ένα μικρό δίκτυο δεν έχει νόημα να χρησιμοποιείτε πάνω από έναν τοπικό name server, εκτός βέβαια κι αν το κάνετε για εκπαιδευτικούς λόγους. Το pfSense όμως είναι σε θέση να εξυπηρετεί περισσότερα από ένα δίκτυα. Ίσως, π.χ., στο LAN interface να βρίσκονται μόνο wired clients, ενώ στο OPT1 μόνο wireless clients κι αυτοί να θέλετε να εξυπηρετούνται μέσω άλλου name server.

Υπάρχουν κι άλλες δυνατότητες, η ανάλυση των οποίων ξεφεύγει από τους σκοπούς του παρόντος. Θα σημειώσουμε μόνο ότι το pfSnese παρέχει μεγάλη ευελιξία κι αξίζει να το γνωρίσετε. Αν όχι για χρήση στο σπίτι, τότε σίγουρα για το εργαστήριο στο σχολείο, για το χώρο εργασίας κ.ο.κ. Δείτε τα ακόλουθα screenshots και διαβάστε τις αντίστοιχες περιγραφές. Ελπίζουμε να εμπνευστείτε λίγο περισσότερο και, γιατί όχι, ν’ αλλάξετε εντελώς τα χαρακτηριστικά των δικτύων για τα οποία είστε υπεύθυνος.

Στις γενικές ρυθμίσεις του pfSense πρέπει να υπάρχει η διεύθυνση IP τουλάχιστον ενός name server -- και στο παράδειγμα υπάρχουν οι διευθύνσεις IP των δύο δημοσίων name servers της Google.Στις γενικές ρυθμίσεις του pfSense πρέπει να υπάρχει η διεύθυνση IP τουλάχιστον ενός name server – και στο παράδειγμα υπάρχουν οι διευθύνσεις IP των δύο δημοσίων name servers της Google. Τώρα, καθένας από τους δύο προεγκατεστημένους στο pfSense name servers είναι δυνατόν να χρησιμοποιεί, όταν φυσικά είναι ενεργοποιημένος, εκείνους που έχουμε πληκτρολογήσει εδώ. Ακριβέστερα, ο DNS Forwarder (πρόκειται για το Dnsmasq) τους χρησιμοποιεί εξ ορισμού, ενώ ο DNS Resolver (πρόκειται για το Unbound) τους χρησιμοποιεί μόνον όταν λειτουργεί ως απλός forwarder (κι όχι ως resolver).

Οι δύο διαθέσιμοι name servers του pfSense, στο μενού Services: έναν από τους δύο χρησιμοποιούν οι clients του router, εκτός κι αν για κάποια μηχανήματα ή ολόκληρα δίκτυα έχουμε ορίσει εξαιρέσεις.Οι δύο διαθέσιμοι name servers του pfSense, στο μενού Services: έναν από τους δύο χρησιμοποιούν οι clients του router, εκτός κι αν για κάποια μηχανήματα ή ολόκληρα δίκτυα έχουμε ορίσει εξαιρέσεις. Πριν την έκδοση 2.2 του pfSense παρών ήταν μόνον ο DNS Forwarder (το Dnsmasq). Από την έκδοση 2.2 και μετά υπάρχει κι ο DNS Resolver (το Unbound). Στις νέες εγκαταστάσεις του pfSense ενεργοποιημένος είναι ο DNS Resolver.

Η προκαθορισμένη συμπεριφορά στον DNS Resolver (Unbound) είναι να τιμά τ' όνομά του, δηλαδή να λειτουργεί ως resolver. Αν όμως θέλουμε να ελαφρύνουμε κάπως τον φόρτο εργασίας του router, τότε κάλλιστα μπορούμε να ζητήσουμε από το Unbound να λειτουργεί ως forwarder.Η προκαθορισμένη συμπεριφορά στον DNS Resolver (Unbound) είναι να τιμά τ’ όνομά του, δηλαδή να λειτουργεί ως resolver. Αν όμως θέλουμε να ελαφρύνουμε κάπως τον φόρτο εργασίας του router, τότε κάλλιστα μπορούμε να ζητήσουμε από το Unbound να λειτουργεί ως forwarder. Σ’ αυτή την περίπτωση η υποστήριξη DNSSEC από πλευράς Unbound πρέπει να ‘ναι ενεργοποιημένη και οι upstream DNS servers επίσης να υποστηρίζουν το DNSSEC (συμβαίνει με τους public DNS servers της Google). Περιττό επίσης να υπογραμμίσουμε ότι οι upstream DNS servers θα πρέπει να είναι της εμπιστοσύνης μας. Εμείς, π.χ., χωρίς να έχουμε βάσιμους λόγους αλλά κυρίως ως θέμα αρχής, δεν εμπιστευόμαστε τoυς name servers των ISPs. Με εκείνους της Google όμως αισθανόμαστε πιο άνετα. Τέλος, έχετε κατά νου πως η λειτουργία του Unbound ως forwarder είναι υποχρεωτική για όσους βγαίνουν στο Internet από δύο ή περισσότερες διαφορετικές συνδέσεις (αναφερόμαστε στο λεγόμενο multi-WAN που υποστηρίζει το pfSense, σε διαμορφώσεις load balancing ή failover).

Ιδού οι clients που αυτή τη στιγμή είναι συνδεδεμένοι απευθείας στο pfSense μας (μέσω των LAN και OPT1 interfaces). Όλοι τους υιοθετούν το dynamic networking configuration, γεγονός που σημαίνει ότι τις τιμές για τις βασικές παραμέτρους δικτύωσης (IP address, router address, DNS κ.ά.) τις λαμβάνουν από τον διαθέσιμο DHCP server.Ιδού οι clients που αυτή τη στιγμή είναι συνδεδεμένοι απευθείας στο pfSense μας (μέσω των LAN και OPT1 interfaces). Όλοι τους υιοθετούν το dynamic networking configuration, γεγονός που σημαίνει ότι τις τιμές για τις βασικές παραμέτρους δικτύωσης (IP address, router address, DNS κ.ά.) τις λαμβάνουν από τον διαθέσιμο DHCP server. Για τους τέσσερις εικονιζόμενους clients έχουμε ζητήσει από τον DHCP του pfSense να τους δίνει πάντα την ίδια διεύθυνση IP (τους clients τους ξεχωρίζει με βάση το MAC address). Γι’ αυτό και στη στήλη Lease Type αναγράφεται παντού αυτό το “static”. Ως προς τη διαμόρφωση των παραμέτρων δικτύωσης των clients, ο DHCP του pfSense παρέχει ακόμα μεγαλύτερη ευελιξία. Διαβάστε παρακάτω.

Παράδειγμα της ευελιξίας που παρέχει ο DHCP server του pfSense.Παράδειγμα της ευελιξίας που παρέχει ο DHCP server του pfSense: Ειδικά για τον client με διεύθυνση IP την 192.168.2.250 (και hostname αυτό το κάπως μυστηριώδες thehost), δεν χρησιμοποιείται κάποιος από τους name servers του συστήματος (Dnsmasq και Unbound) αλλά εκείνος στο 192.168.2.5.

Ο DHCP server του pfSense box είναι ενεργοποιημένος για τα LAN και OPT1 network interfaces κι εξυπηρετεί τους πελάτες που συνδέονται σε καθένα εξ αυτών.Ο DHCP server του pfSense box είναι ενεργοποιημένος για τα LAN και OPT1 network interfaces κι εξυπηρετεί τους πελάτες που συνδέονται σε καθένα εξ αυτών. Στο screenshot βλέπουμε το OPT1 interface (1). Ο DHCP μοιράζει δυναμικά διευθύνσεις IP μεταξύ 192.168.3.150 και 192.168.3.175 συμπεριλαμβανομένων. Στα μηχανήματα πάνω στο OPT1, τα οποία χρησιμοποιούν dynamic networking configuration και συνεπώς εξυπηρετούνται από τον DHCP, ο name server που τους γνωστοποιείται είναι ο 192.168.3.5 (2) κι όχι κάποιος από εκείνους που διαθέτει το pfSense (Dnsmasq και Unbound). Γιατί θα θέλαμε μια τέτοια διευθέτηση; Για πολλούς λόγους, αλλά προς το παρόν θα αναφέρουμε μόνον έναν: Ο name server στο 192.168.3.5 θα μπορούσε να κάνει το resolving μέσω του δικτύου ανωνυμίας Tor, επομένως τα DNS requests των πελατών πίσω από το OPT1 θα ήταν, πρακτικά, ανώνυμα. Παρατηρήστε τέλος και τη θυρίδα Gateway, λίγο πιο κάτω: Με την κατάλληλη προεργασία, οι πελάτες του OPT1 θα ήταν να δυνατόν να βγαίνουν στον έξω κόσμο μέσω του Tor, φυσικά χωρίς να τους έχουμε εγκαταστήσει έξτρα λογισμικό.

Άρθρα της σειράς

Εισαγωγή στο Domain Name System

Οι name servers στο μικροσκόπιο

Zone files και resource records

Ο δικός μας caching name server

Στρατηγικές εκμετάλλευσης του name server μας

Σας άρεσε το post; Αν ναι μπορείτε να στηρίξετε το ðhacker, χωρίς κατ’ ανάγκη να ξοδέψετε χρήματα.