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

Περιορισμός του bandwidth για τους αχόρταγους

Είστε ο υπεύθυνος διαχειριστής ενός δικτύου. Παρατηρείτε ότι κάποιες ώρες μέσα στην ημέρα γίνεται κατάχρηση του bandwidth. Την ίδια στιγμή αρκετοί χρήστες δεν μπορούν να κάνουν τη δουλειά τους. Γίνεστε, φυσικά, ο αποδέκτης των παραπόνων τους. Ποιοι και πώς προκαλούν όλη αυτή την αναστάτωση; Τι μπορείτε να κάνετε ώστε να μην έχετε τέτοιου είδους προβλήματα, από τώρα και στο μέλλον;

Αναλόγως του bandwidth που διατίθεται για ένα τοπικό δίκτυο, ένας ή δύο χρήστες είναι δυνατόν να το εκμεταλλεύονται σχεδόν αποκλειστικά. Ως αποτέλεσμα, εντελώς ξαφνικά όλοι οι άλλοι χρήστες δυσκολεύονται να κάνουν ακόμη και απλές εργασίες, όπως, π.χ., λήψη email ή web browsing. Η αλήθεια είναι ότι το πρόβλημα με τους λεγόμενους “bandwidth hogs” προκύπτει αρκετά συχνά. Αν μιλάμε για ένα μικρό δίκτυο ο εντοπισμός τους είναι απλός και, προκειμένου να μην έχουμε ξανά παρόμοια προβλήματα στο μέλλον, μερικές συστάσεις ενδεχομένως να αρκούν. Όμως ο καλός διαχειριστής δικτύων δεν σκέφτεται τόσο απλοϊκά — για την ακρίβεια σπάνια έχει αυτή την πολυτέλεια. Πέρα από τις συστάσεις γνωρίζει ότι είναι σημαντικό να επιβάλλει, κεντρικά και με τεχνικά μέσα, συγκεκριμένες πολιτικές συνετής χρήσης.

Στο παρόν άρθρο θα δούμε πώς ανακαλύπτουμε τι προκαλεί την υπερβολική κατανάλωση bandwidth, καθώς και τα μηχανήματα που εμπλέκονται. Γι’ αυτή τη δουλειά θα καταφύγουμε στις υπηρεσίες του packet analyzer ονόματι Wireshark. Υποθέτουμε επίσης ότι έχουμε πλήρη πρόσβαση στον router του τοπικού δικτύου, ο οποίος τρέχει το pfSense. Αντί για το pfSense θα μπορούσε να τρέχει το OpenBSD ή κάποια διανομή Linux. Σε κάθε περίπτωση, καταλαβαίνετε ότι δεν μιλάμε για ένα απλό consumer grade router αλλά για κάτι πιο ευέλικτο. Αυτό πάντως που κυρίως μας ενδιαφέρει να παρακολουθήσουμε είναι το σκεπτικό του διαχειριστή δικτύου και, κυρίως, το πώς υλοποιεί μια πολιτική ώστε οι bandwidth hogs να μη δημιουργούν προβλήματα. Έχετε υπόψη ότι τέτοιου είδους πολιτικές δεν βρίσκουν εφαρμογή μόνο σε χώρους εργασίας, αλλά και σε σχολικά/πανεπιστημιακά εργαστήρια ή ακόμη και σε οικιακά δίκτυα, όπου κάποια μέλη έχουν μεγάλο έρωτα με το BitTorrent.

Σημείωση. Μια καλή εισαγωγή στο Wireshark γίνεται στο δεύτερο άρθρο της μίνι σειράς περί packet analysis, στο τεύχος 020 του περιοδικού. Σχετικά με το pfSense, εξάλλου, το αγαπημένο μας λειτουργικό σύστημα για χρήση router/firewall, μπορείτε να παρακολουθήσετε το εκτενές deltaCast s01e07.

Παρατήρηση του προβλήματος και διερεύνηση
Μέσα από το web panel του pfSense έχουμε πρόσβαση σε μια σειρά από γραφήματα που οπτικοποιούν διάφορες όψεις της συμπεριφοράς του router, καθώς και της κατάστασης που επικρατεί στο τοπικό δίκτυο. Συγκεκριμένα, δίνοντας Status –> RDP Graphs κι επιλέγοντας την καρτέλα Traffic, παρακολουθούμε ζωντανά τη δικτυακή κίνηση σε καθένα από τα network interfaces του router. Κάθε φορά που γίνεται κατάχρηση του bandwidth το γεγονός αντικατοπτρίζεται στο γράφημα για το WAN, που είναι το interface με το οποίο το pfSense επικοινωνεί με τον έξω κόσμο. Εκτός από κάποιες –πρακτικά στιγμιαίες– εξάρσεις στη χρήση του bandwidth, τα χρονικά διαστήματα όπου έχουμε κατάχρηση απεικονίζονται ξεκάθαρα. Παρατηρήστε, π.χ., το ακόλουθο screenshot.

Γραφική αναπαράσταση της δικτυακής κίνησης για το WAN interface του router μας. Υπάρχουν κάποιες περιπτώσεις στιγμιαίας, πρακτικά, έξαρσης στη χρήση bandwidth, οι οποίες δεν δημιουργούν κανένα πρόβλημα απολύτως [βλ. (1)]. Η κατάσταση αλλάζει δραματικά όταν έχουμε παρατεταμένο downloading που αφενός φτάνει στο άνω όριο της γραμμής μας, αφετέρου διαρκεί για αρκετό χρόνο [βλ. (2) και (3)]. Σκεφτείτε ότι όλη αυτή η 'κατανάλωση' πιθανώς να οφείλεται σε ένα μόνο μηχάνημα του τοπικού δικτύου, είναι όμως αρκετή ώστε όλοι οι χρήστες να βιώνουν αισθητά περιορισμένη ταχύτητα σύνδεσης, ακόμη και για δραστηριότητες όπως, π.χ., το απλό web browsing.

Γραφική αναπαράσταση της δικτυακής κίνησης για το WAN interface του router μας. Υπάρχουν κάποιες περιπτώσεις στιγμιαίας, πρακτικά, έξαρσης στη χρήση bandwidth, οι οποίες δεν δημιουργούν κανένα πρόβλημα απολύτως [βλ. (1)]. Η κατάσταση αλλάζει δραματικά όταν έχουμε παρατεταμένο downloading που αφενός φτάνει στο άνω όριο της γραμμής μας, αφετέρου διαρκεί για αρκετό χρόνο [βλ. (2) και (3)]. Σκεφτείτε ότι όλη αυτή η “κατανάλωση” πιθανώς να οφείλεται σε ένα μόνο μηχάνημα του τοπικού δικτύου, είναι όμως αρκετή ώστε όλοι οι χρήστες να βιώνουν αισθητά περιορισμένη ταχύτητα σύνδεσης, ακόμη και για δραστηριότητες όπως, π.χ., το απλό web browsing.

Θέλοντας να δούμε καλύτερα τι συμβαίνει, δηλαδή ποια μηχανήματα είναι υπεύθυνα για την κατάχρηση και, αν είναι δυνατόν, τι περίπου κάνουν, μια λύση είναι να ξεκινήσουμε μερικά δοκιμαστικά packet captures στο interface που βλέπουν οι πελάτες του pfSense. Το εν λόγω interface για πολλούς θα είναι το LAN, αν κι αυτό δεν είναι απαραίτητο. Στο δικό μας pfSense box, π.χ., το interface που βλέπουν οι clients είναι το OPT2 (bridge των OPT1 και LAN). Προσέξτε: Με packet capture στο WAN ναι μεν θα βλέπουμε με ποια hosts στο Internet επικοινωνεί ο router, αλλά όχι ποια μηχανήματα πίσω του έχουν ξεκινήσει τις αντίστοιχες συνδέσεις. Περιττό να σημειώσουμε ότι τα packet captures καλό είναι να γίνονται όταν παρατηρείται έντονη δικτυακή δραστηριότητα. Τώρα, προκειμένου να ξεκινήσουμε την καταγραφή των πακέτων, από το web panel του pfSense ακολουθούμε τη διαδρομή Disgnostics –> Packet Capture.

Έτοιμοι για ένα packet capture στο OPT2 (1), το οποίο για την περίπτωσή μας είναι το network interface του router που βλέπουν τα μηχανήματα του τοπικού δικτύου. Αφήνουμε τις προεπιλογές φροντίζοντας μόνο ώστε να ισχύει Count = 0 (2). Έτσι, η καταγραφή των πακέτων θα συνεχίζεται έως ότου αποφασίσουμε να τη διακόψουμε. Η διαδικασία ξεκινά με ένα κλικ στο κουμπί Start (3).

Έτοιμοι για ένα packet capture στο OPT2 (1), το οποίο για την περίπτωσή μας είναι το network interface του router που βλέπουν τα μηχανήματα του τοπικού δικτύου. Αφήνουμε τις προεπιλογές φροντίζοντας μόνο ώστε να ισχύει Count = 0 (2). Έτσι, η καταγραφή των πακέτων θα συνεχίζεται έως ότου αποφασίσουμε να τη διακόψουμε. Η διαδικασία ξεκινά με ένα κλικ στο κουμπί Start (3).

Αφού σταματήσουμε τη διαδικασία της καταγραφής με κλικ στο κουμπί Stop, κάνουμε κι άλλο ένα στο Download Capture. Κατεβάζουμε έτσι το αρχείο ονόματι packetcapture.cap, με όλα τα δικτυακά πακέτα που κατεγράφησαν μόλις. Έχετε υπόψη ότι αν το μέγεθος του αρχείου είναι μεγάλο, ίσως χρειαστεί να περιμένετε λίγο έως ότου ο web browser αρχίσει και πάλι ν' αποκρίνεται. Αν δείτε ότι αργεί να επανέλθει απλά κάντε ένα refresh στη σελίδα και μετά πατήστε ξανά στο Download Capture.

Αφού σταματήσουμε τη διαδικασία της καταγραφής με κλικ στο κουμπί Stop, κάνουμε κι άλλο ένα στο Download Capture. Κατεβάζουμε έτσι το αρχείο ονόματι packetcapture.cap, με όλα τα δικτυακά πακέτα που κατεγράφησαν μόλις. Έχετε υπόψη ότι αν το μέγεθος του αρχείου είναι μεγάλο, ίσως χρειαστεί να περιμένετε λίγο έως ότου ο web browser αρχίσει και πάλι ν’ αποκρίνεται. Αν δείτε ότι αργεί να επανέλθει απλά κάντε ένα refresh στη σελίδα και μετά πατήστε ξανά στο Download Capture.

Ανάλυση με το Wireshark
Δουλεύουμε σε περιβάλλον Windows 10 και με την εκδοχή 64bit της πλέον πρόσφατης έκδοσης του Wireshark (2.0.0). Αφού τρέξουμε την εφαρμογή δίνουμε File –> Open, μεταβαίνουμε στο φάκελο όπου βρίσκεται το αρχείο packetcapture.cap που πήραμε από το pfSense, το επιλέγουμε και τ’ ανοίγουμε. Στο δικό μας παράδειγμα, ταξινομώντας ως προς το πρωτόκολλο (βλ. στήλη Protocol) είναι εύκολο να διαπιστώσουμε ότι γίνεται χρήση του BitTorrent. Αυτό όμως από μόνο του δεν αποτελεί απόδειξη για κατάχρηση.

Ταξινομώντας ως προς το πρωτόκολλο (1) είναι εύκολο να δούμε ότι γίνεται χρήση του BitTorrent, καθώς κι ότι εμπλέκονται τουλάχιστον δύο μηχανήματα του τοπικού δικτύου (2, 3). Προς το παρόν, ωστόσο, δεν μπορούμε να είμαστε σίγουροι ότι γίνεται *και* κατάχρηση του bandwidth.

Ταξινομώντας ως προς το πρωτόκολλο (1) είναι εύκολο να δούμε ότι γίνεται χρήση του BitTorrent, καθώς κι ότι εμπλέκονται τουλάχιστον δύο μηχανήματα του τοπικού δικτύου (2, 3). Προς το παρόν, ωστόσο, δεν μπορούμε να είμαστε σίγουροι ότι γίνεται *και* κατάχρηση του bandwidth.

Για ν’ αποκτήσουμε μια πολύ καλύτερη εικόνα όσον αφορά στα πρωτόκολλα που έπαιζαν στο τοπικό μας δίκτυο κατά τη διάρκεια του capture, από το μενού του Wireshark επιλέγουμε Statistics –> Protocol Hierarchy. Αναλόγως του μεγέθους που έχει το capture file ίσως χρειαστεί να περιμένουμε λίγο, τελικά όμως θα εμφανιστεί το παράθυρο ονόματι Protocol Hierarchy Statistics. Σ’ αυτό παρατηρούμε ότι τα πακέτα του capture file, σε ποσοστό 92,7% είναι του πρωτοκόλλου μεταφοράς TCP. Από αυτά, το 53,5% αφορούν στο πρωτόκολλο εφαρμογής BitTorrent κι όλα μαζί αντιστοιχούν στο 87,4% των διακινούμενων bytes. Ο δε ρυθμός διακίνησής τους ήταν περί τα 9,3Mbps, τη στιγμή που η πραγματική ταχύτητα σύνδεσης του δικτύου μας με τον έξω κόσμο είναι κοντά στα 11Mbps. Νομίζουμε πως θα συμφωνήσετε κι εσείς ότι έχει παραγίνει το κακό με το BitTorrent.

Τα πακέτα του capture file, σε ποσοστό 92,7% είναι του πρωτοκόλλου μεταφοράς TCP (1). Από αυτά, το 53,5% αφορούν στο πρωτόκολλο εφαρμογής BitTorrent (2) κι όλα μαζί αντιστοιχούν στο  87,4% των διακινούμενων bytes (3). Ο δε ρυθμός διακίνησής τους ήταν περί τα 9,3Mbps (4), τη στιγμή που η πραγματική ταχύτητα σύνδεσης του δικτύου μας με τον έξω κόσμο είναι κοντά στα 11Mbps!

Τα πακέτα του capture file, σε ποσοστό 92,7% είναι του πρωτοκόλλου μεταφοράς TCP (1). Από αυτά, το 53,5% αφορούν στο πρωτόκολλο εφαρμογής BitTorrent (2) κι όλα μαζί αντιστοιχούν στο 87,4% των διακινούμενων bytes (3). Ο δε ρυθμός διακίνησής τους ήταν περί τα 9,3Mbps (4), τη στιγμή που η πραγματική ταχύτητα σύνδεσης του δικτύου μας με τον έξω κόσμο είναι κοντά στα 11Mbps!

Για να έχουμε στο κεντρικό πλαίσιο του Wireshark μόνο τα BitTorrent packets, στη θυρίδα Expression (στο πάνω μέρος της εφαρμογής) πληκτρολογούμε “bittorrent” (χωρίς τα εισαγωγικά) και πατάμε το [Enter]. Θέλουμε τώρα να βρούμε ποια μηχανήματα του τοπικού δικτύου, που στο παράδειγμά μας έχουν διευθύνσεις IP της μορφής 192.168.10.*, εμπλέκονται σε όλο αυτό το torrenting. Προς τούτο επιλέγουμε Statistics –> Endpoints, στο νέο παράθυρο που εμφανίζεται, με όνομα Wireshark – Endpoints – packetcapture, κάνουμε κλικ στην καρτέλα IPv4, μετά τσεκάρουμε και το κουτάκι Limit to display filter. Αμέσως βλέπουμε ότι τα μηχανήματα από τα οποία γίνεται το downloading μέσω BitTorrent είναι τα 192.168.10.154 και 192.168.10.160.

Ιδού οι δύο υπαίτιοι για την κατάχρηση του bandwidth στο τοπικό μας δίκτυο. Τώρα που τους εντοπίσαμε, μένει να αποφασίσουμε πώς θα τους περιορίσουμε.

Ιδού οι δύο υπαίτιοι για την κατάχρηση του bandwidth στο τοπικό μας δίκτυο. Τώρα που τους εντοπίσαμε, μένει να αποφασίσουμε πώς θα τους περιορίσουμε.

Στρατηγική αντιμετώπισης
Υπάρχουν πολλά που μπορεί να κάνει ο διαχειριστής ενός δικτύου, προκειμένου να εμποδίσει τους bandwidth hogs από το να προκαλέσουν ξανά προβλήματα στο μέλλον. Μια πρώτη σκέψη είναι να τους απαγορεύεται η πρόσβαση στο Internet, έστω για συγκεκριμένα χρονικά διαστήματα μέσα στο 24ωρο. Θα συμφωνήσετε κι εσείς, φανταζόμαστε, ότι πρόκειται για δρακόντειο μέτρο. Ούτε στο χειρότερο εχθρό μας, ένα πράγμα. Μια ηπιότερη λύση, η οποία φαίνεται να ‘χει καλές πιθανότητες να νουθετήσει τους bandwidth hogs επιτρέποντάς τους ταυτόχρονα την πρόσβαση στο Internet, θα ήταν ο περιορισμός του διαθέσιμου bandwidth για εκείνους και μόνο — είτε επί μονίμου βάσεως είτε για συγκεκριμένα διαστήματα μέσα στο 24ωρο.

Είμαστε υπέρ αυτής της δεύτερης προσέγγισης και στο υπόλοιπο του παρόντος εξηγούμε πώς υλοποιείται η σχετική πολιτική. Συγκεκριμένα:

  • βάζουμε όλους τους bandwidth hogs στην ίδια λίστα
  • ορίζουμε ένα χρονικό διάστημα μέσα στο 24ωρο για τις καθημερινές (όχι για τα σαββατοκύριακα), κατά το οποίο η κατάχρηση του bandwidth πρέπει να αποτρέπεται
  • θέτουμε φίλτρα για τον περιορισμό του download, αλλά και του upload rate
  • προσθέτουμε έναν νέο κανόνα στο firewall ώστε τα προαναφερθέντα φίλτρα να ισχύουν *μόνο* για τους bandwidth hogs και *μόνο* για το ορισθέν χρονικό διάστημα κατά τις καθημερινές

Όλα τα προηγούμενα υλοποιούνται μέσα από το web panel του pfSense και σε πολύ λίγο θα παραθέσουμε όλες τις λεπτομέρειες. Πριν όμως ξεκινήσουμε, να κάνουμε και μια απαραίτητη σημείωση. Στο πλαίσιο του παραδείγματός μας οι bandwidth hogs είναι τα μηχανήματα με διευθύνσεις IP 192.168.10.154 και 192.168.10.160. Αν αυτά δεν έχουν static IP configuration, τότε οι διευθύνσεις IP κάποια στιγμή είναι πολύ πιθανό ν’ αλλάξουν κι ως αποτέλεσμα οι περιορισμοί που θα έχουμε θέσει θα πάψουν να ισχύουν ή, ακόμα χειρότερα, θα ισχύουν για τα λάθος μηχανήματα. Ένας τρόπος για ν’ αποφύγουμε το πρόβλημα είναι να ρυθμίσουμε τον DHCP server του pfSense, ώστε να δίνει πάντα τις ίδιες διευθύνσεις στους bandwidth hogs. Οι αποδόσεις των διευθύνσεων θα γίνονται βάσει MAC addresses και θα βρίσκονται εκτός του διαστήματος διευθύνσεων που μοιράζει αυτόματα ο DHCP server. Το πώς πετυχαίνουμε κάτι τέτοιο το έχουμε δείξει αρκετές φορές στο παρελθόν (hint: ξεκινήστε από το Status –> DHCP Leases). Με βάση τις αναθέσεις διευθύνσεων που εμείς κάναμε, οι δύο bandwidth hogs για τη συνέχεια θα είναι οι 192.168.10.90 και 192.168.10.91.

Φροντίσαμε ώστε στους δύο bandwidth hogs του τοπικού μας δικτύου να αποδίδονται πάντα οι ίδιες διευθύνσεις IP. Έτσι, οι περιορισμοί που σε λίγο θα υλοποιήσουμε θα ισχύουν για τους πραγματικούς υπαίτιους της κατάχρησης bandwidth και μόνον για εκείνους.

Φροντίσαμε ώστε στους δύο bandwidth hogs του τοπικού μας δικτύου να αποδίδονται πάντα οι ίδιες διευθύνσεις IP. Έτσι, οι περιορισμοί που σε λίγο θα υλοποιήσουμε θα ισχύουν για τους πραγματικούς υπαίτιους της κατάχρησης bandwidth και μόνον για εκείνους.

Λίστα με τους bandwidth hogs και ώρες γραφείου
Θέλουμε μία λίστα με τις διευθύνσεις IP των μηχανημάτων από τα οποία γίνεται κατάχρηση του bandwidth. Φυσικά, σ’ αυτή τη λίστα θα πρέπει να έχουμε το ελεύθερο για την απομάκρυνση ή/και την προσθήκη διευθύνσεων IP. Αυτό που χρειαζόμαστε είναι ένα νέο alias και για να το ορίσουμε ακολουθούμε τη διαδρομή Firewall –> Aliases.

Το alias ονόματι Bandwidth_Hogs, στο οποίο προς το παρόν έχουμε βάλει τα IP των δύο μηχανημάτων από τα οποία αποδεδειγμένα γίνεται κατάχρηση του bandwidth. Εννοείται ότι ανά πάσα στιγμή μπορούμε να προσθαφαιρούμε IPs στην αντίστοιχη λίστα.

Το alias ονόματι Bandwidth_Hogs, στο οποίο προς το παρόν έχουμε βάλει τα IP των δύο μηχανημάτων από τα οποία αποδεδειγμένα γίνεται κατάχρηση του bandwidth. Εννοείται ότι ανά πάσα στιγμή μπορούμε να προσθαφαιρούμε IPs στην αντίστοιχη λίστα.

Στη συνέχεια θα ορίσουμε ένα χρονικό διάστημα για τις καθημερινές, κατά το οποίο το bandwidth για όσους είναι στη λίστα Bandwidth_Hogs θα είναι περιορισμένο. Θα δούμε σε λίγο πώς υλοποιείται κάτι τέτοιο. Προς το παρόν, από το μενού του pfSense δίνουμε Firewall –> Schedules και κάνουμε ένα κλικ στο κουμπάκι [+], κάτω δεξιά, ώστε να ορίσουμε το νέο “πρόγραμμα” (schedule) που θέλουμε.

Το νέο schedule το ονομάσαμε Office_Hours κι αφορά στις ώρες από 10 το πρωί έως 6 το απόγευμα, για τις εργάσιμες ημέρες (από Δευτέρα έως Παρασκευή) κάθε εβδομάδας. Σημειώστε ότι με κλικ στο όνομα της ημέρας (κορυφή στήλης), επιλέγονται όλες οι αντίστοιχες μέρες του μήνα. Επίσης, παίζοντας λίγο με το drop-down μενού ονόματι Month παρατηρούμε ότι έχουν επιλεγεί οι αντίστοιχες μέρες κάθε μήνα. Για να συμπεριληφθεί στο schedule μας το χρονικό διάστημα που ορίζουμε στην περιοχή Time, αρκεί ένα κλικ στο κουμπάκι Add Time.

Το νέο schedule το ονομάσαμε Office_Hours κι αφορά στις ώρες από 10 το πρωί έως 6 το απόγευμα, για τις εργάσιμες ημέρες (από Δευτέρα έως Παρασκευή) κάθε εβδομάδας. Σημειώστε ότι με κλικ στο όνομα της ημέρας (κορυφή στήλης), επιλέγονται όλες οι αντίστοιχες μέρες του μήνα. Επίσης, παίζοντας λίγο με το drop-down μενού ονόματι Month παρατηρούμε ότι έχουν επιλεγεί οι αντίστοιχες μέρες κάθε μήνα. Για να συμπεριληφθεί στο schedule μας το χρονικό διάστημα που ορίζουμε στην περιοχή Time, αρκεί ένα κλικ στο κουμπάκι Add Time.

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

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

pqrxyz

Το schedule μας με τις εργάσιμες μέρες κάθε μήνα είναι έτοιμο.

Limiters για upload και download
Επόμενη κίνησή μας είναι να ορίσουμε δύο limiters ή φίλτρα, ένα για την ταχύτητα download κι άλλο ένα για την ταχύτητα upload. Αυτά τα φίλτρα θα εφαρμόζονται από κατάλληλο κανόνα του firewall στους υπολογιστές του alias ονόματι Bandwidth_Hosts. Για τον ορισμό ενός limiter ακολουθούμε τη διαδρομή Firewall –> Traffic Shaper –> Limiter και κάνουμε ένα κλικ στον σύνδεσμο “[+] Create new limiter”. Δείτε τα screenshots που ακολουθούν και βεβαίως διαβάστε τις αντίστοιχες περιγραφές.

Τον limiter για το download εμείς τον ονομάσαμε LimitDown (θυρίδα Name) κι ως μέγιστη ταχύτητα ορίσαμε τα 2Mbps. Νομίζουμε ότι είναι υπεραρκετή για να παίρνει κάποιος το email του, δεν συμφωνείτε; Στην περιοχή Mask και συγκεκριμένα στο drop-down μενού πάνω πάνω, επιλέξαμε Destination address. Κατ' αυτόν τον τρόπο ο limiter αφορά στο ρυθμό λήψης πακέτων που λαμβάνει κάποιο μηχάνημα του τοπικού μας δικτύου, μ' άλλα λόγια στην ταχύτητα download που μπορεί να έχει. Για να θυμόμαστε αμέσως τι κάνει, γράφουμε αν θέλουμε κάτι περιγραφικό στη θυρίδα Description. Ο limiter δημιουργείται με τσεκάρισμα του Enable limiter and its children, πάνω, βεβαίως και μ' ένα κλικ στο κουμπάκι Save, κάτω.

Τον limiter για το download εμείς τον ονομάσαμε LimitDown (θυρίδα Name) κι ως μέγιστη ταχύτητα ορίσαμε τα 2Mbps. Νομίζουμε ότι είναι υπεραρκετή για να παίρνει κάποιος το email του, δεν συμφωνείτε; Στην περιοχή Mask και συγκεκριμένα στο drop-down μενού πάνω πάνω, επιλέξαμε Destination address. Κατ’ αυτόν τον τρόπο ο limiter αφορά στο ρυθμό λήψης πακέτων που λαμβάνει κάποιο μηχάνημα του τοπικού μας δικτύου, μ’ άλλα λόγια στην ταχύτητα download που μπορεί να έχει. Για να θυμόμαστε αμέσως τι κάνει, γράφουμε αν θέλουμε κάτι περιγραφικό στη θυρίδα Description. Ο limiter δημιουργείται με τσεκάρισμα του Enable limiter and its children, πάνω, βεβαίως και μ’ ένα κλικ στο κουμπάκι Save, κάτω.

Ιδού ο πρώτος μας limiter, ο οποίος αφορά στο download. Θέλουμε κι έναν για το upload, οπότε κάνουμε ένα κλικ στο Create new limiter.

Ιδού ο πρώτος μας limiter, ο οποίος αφορά στο download. Θέλουμε κι έναν για το upload, οπότε κάνουμε ένα κλικ στο Create new limiter.

Τον δεύτερο limiter, ο οποίος αφορά στο upload, ονομάσαμε LimitUp κι ως μέγιστη ταχύτητα του ορίσαμε τα 256Kbps. Στο drop-down μενού της περιοχής Mask, αυτή τη φορά επιλέξαμε το Source address.

Τον δεύτερο limiter, ο οποίος αφορά στο upload, ονομάσαμε LimitUp κι ως μέγιστη ταχύτητα του ορίσαμε τα 256Kbps. Στο drop-down μενού της περιοχής Mask, αυτή τη φορά επιλέξαμε το Source address.

Οι δύο limiters, ο ένας για το download κι ο άλλος για το upload, είναι έτοιμοι. Βέβαια από μόνοι τους δεν κάνουν κάτι. Γι' αυτό και σε λίγο θα ορίσουμε ένα νέο κανόνα για το firewall που θα τους αξιοποιεί, ώστε κατά τις ώρες γραφείου οι bandwidth hogs να περιορίζονται.

Οι δύο limiters, ο ένας για το download κι ο άλλος για το upload, είναι έτοιμοι. Βέβαια από μόνοι τους δεν κάνουν κάτι. Γι’ αυτό και σε λίγο θα ορίσουμε ένα νέο κανόνα για το firewall που θα τους αξιοποιεί, ώστε κατά τις ώρες γραφείου οι bandwidth hogs να περιορίζονται.

Περιοριστικός κανόνας στο firewall
Ως εδώ έχουμε ολοκληρώσει με επιτυχία τις ακόλουθες εργασίες:

  • εντοπίσαμε τις διευθύνσεις IP των μηχανημάτων του τοπικού δικτύου, από τα οποία γίνεται κατάχρηση του bandwidth
  • φροντίσαμε ώστε τα εν λόγω μηχανήματα (bandwidth hogs) να παίρνουν πάντοτε τις ίδιες διευθύνσεις IP, από τον DHCP server του pfSense
  • φτιάξαμε ένα alias με τις διευθύσεις IP των bandwidth hogs
  • περιγράψαμε ένα πρόγραμμα (schedule), κατά το οποίο ορίζονται οι εργάσιμες ώρες μέσα στις καθημερινές μέρες κάθε μήνα
  • δημιουργήσαμε δύο φίλτρα (limiters), ένα για το download κι ένα για το upload.

Μένει τώρα να ορίσουμε έναν νέο κανόνα στο firewall του pfSense ο οποίος θα συνδυάζει *όλα* τα προηγούμενα, ώστε οι bandwidth hogs να περιορίζονται κατά τη διάρκεια των εργάσιμων ημερών και ωρών. Δείτε τα screenshots που ακολουθούν.

Ο κανόνας θα αφορά σε πακέτα ανεξαρτήτως πρωτοκόλλου (Protocol = any), που ξεκινούν από μηχανήματα από τα οποία γίνεται κατάχρηση bandwidth (Source: Type = Single host or alias & Address = Bandwidth_Hogs) και *δεν* προορίζονται για άλλα μηχανήματα του τοπικού δικτύου (Destination = not OPT2 net). Προφανώς, αν τα πακέτα προορίζονται για μηχανήματα του τοπικού δικτύου (για εμάς OPT2 net), τότε δεν επιθυμούμε να εφαρμόζεται ο περιοριστικός μας κανόνας. Πηγαίνουμε στη συνέχεια λίγο πιο κάτω στη σελίδα, όπου εκεί συναντάμε τις προχωρημένες ρυθμίσεις.

Ο κανόνας θα αφορά σε πακέτα ανεξαρτήτως πρωτοκόλλου (Protocol = any), που ξεκινούν από μηχανήματα από τα οποία γίνεται κατάχρηση bandwidth (Source: Type = Single host or alias & Address = Bandwidth_Hogs) και *δεν* προορίζονται για άλλα μηχανήματα του τοπικού δικτύου (Destination = not OPT2 net). Προφανώς, αν τα πακέτα προορίζονται για μηχανήματα του τοπικού δικτύου (για εμάς OPT2 net), τότε δεν επιθυμούμε να εφαρμόζεται ο περιοριστικός μας κανόνας. Πηγαίνουμε στη συνέχεια λίγο πιο κάτω στη σελίδα, όπου εκεί συναντάμε τις προχωρημένες ρυθμίσεις.

Ο κανόνας θα είναι ενεργός μόνον κατά τις ώρες γραφείου, όλες τις εργάσιμες μέρες της εβδομάδας. Θέτουμε, λοιπόν, Schedule = Office_Hours. O δε gateway μέσω του οποίου τα πακέτα θα βγαίνουν στο Internet δεν χρειάζεται να τεθεί, εκτός αν για τον pfSense router σας υπάρχουν περισσότεροι από ένας gateways. Στον δικό μας, π.χ., πέρα από τον τυπικό έχει οριστεί κι ένας για την επικοινωνία με απομακρυσμένο OpenVPN Access Server (http://deltahacker.gr/?p=15109) που έχουμε στο cloud. Δεν επιθυμούμε οι bandwidth hogs να βγαίνουν στο Internet μέσω του απομακρυσμένου server, οπότε θέτουμε Gateway = WANGW (πρόκειται για το LAN interface του ADSL modem/router μπροστά από το pfSense box). Δώστε τώρα προσοχή στην περιοχή In/Out. Στη θυρίδα του 'In' (αριστερά) επιλέγουμε το φίλτρο LimitUp. Έτσι, ο ρυθμός των πακέτων που ξεκινούν από bandwidth hog και *εισέρχονται* στο OPT2 (κατεύθυνση 'In') θα περιορίζεται όπως περιγράφει ο limiter ονόματι LimitUp. Διαφορετικά: Το upload rate των bandwidth hogs θα είναι το πολύ 256Kbps. Ομοίως εργαζόμαστε για τη θυρίδα του 'Out'. Σ' αυτή επιλέγουμε το φίλτρο LimitDown κι έτσι ο ρυθμός των πακέτων που *εξέρχονται* από το OPT2 και προορίζονται προς κάποιον bandwidth hog περιορίζεται όπως περιγράφει ο limiter ονόματι LimitDown. Διαφορετικά: Το download rate των bandwidth hogs θα είναι το πολύ 2Mbps. Για την επικύρωση του κανόνα κάνουμε ένα κλικ στο κουμπί Save.

Ο κανόνας θα είναι ενεργός μόνον κατά τις ώρες γραφείου, όλες τις εργάσιμες μέρες της εβδομάδας. Θέτουμε, λοιπόν, Schedule = Office_Hours. O δε gateway μέσω του οποίου τα πακέτα θα βγαίνουν στο Internet δεν χρειάζεται να τεθεί, εκτός αν για τον pfSense router σας υπάρχουν περισσότεροι από ένας gateways. Στον δικό μας, π.χ., πέρα από τον τυπικό έχει οριστεί κι ένας για την επικοινωνία με απομακρυσμένο OpenVPN Access Server (http://deltahacker.gr/?p=15109) που έχουμε στο cloud. Δεν επιθυμούμε οι bandwidth hogs να βγαίνουν στο Internet μέσω του απομακρυσμένου server, οπότε θέτουμε Gateway = WANGW (πρόκειται για το LAN interface του ADSL modem/router μπροστά από το pfSense box). Δώστε τώρα προσοχή στην περιοχή In/Out. Στη θυρίδα του “In” (αριστερά) επιλέγουμε το φίλτρο LimitUp. Έτσι, ο ρυθμός των πακέτων που ξεκινούν από bandwidth hog και *εισέρχονται* στο OPT2 (κατεύθυνση “In”) θα περιορίζεται όπως περιγράφει ο limiter ονόματι LimitUp. Διαφορετικά: Το upload rate των bandwidth hogs θα είναι το πολύ 256Kbps. Ομοίως εργαζόμαστε για τη θυρίδα του “Out”. Σ’ αυτή επιλέγουμε το φίλτρο LimitDown κι έτσι ο ρυθμός των πακέτων που *εξέρχονται* από το OPT2 και προορίζονται προς κάποιον bandwidth hog περιορίζεται όπως περιγράφει ο limiter ονόματι LimitDown. Διαφορετικά: Το download rate των bandwidth hogs θα είναι το πολύ 2Mbps. Για την επικύρωση του κανόνα κάνουμε ένα κλικ στο κουμπί Save.

Το κόκκινο κουτάκι με το 'x' εμφανίζεται στη στήλη Schedule όταν ο κανόνας μας είναι απενεργοποιημένος, μ' άλλα λόγια *όχι* κατά τα διαστήματα που ορίζει το πρόγραμμα ονόματι Office_Hours.

Το κόκκινο κουτάκι με το “x” εμφανίζεται στη στήλη Schedule όταν ο κανόνας μας είναι απενεργοποιημένος, μ’ άλλα λόγια *όχι* κατά τα διαστήματα που ορίζει το πρόγραμμα ονόματι Office_Hours.

Όταν ο κανόνας μας είναι ενεργοποιημένος, κατά τις ώρες γραφείου τις καθημερινές, στη θέση του κόκκινου

Όταν ο κανόνας μας είναι ενεργοποιημένος, κατά τις ώρες γραφείου τις καθημερινές, στη θέση του κόκκινου “x” υπάρχει ένα πράσινο τετραγωνάκι.

Νέα εμπειρία για τους αχόρταγους
Μετά την εισαγωγή του νέου μας κανόνα η κατάσταση στο τοπικό δίκτυο πίσω από τον pfSense router αλλάζει δραματικά — αλλά μόνο κατά τη διάρκεια των διαστημάτων που ορίζονται από το Office_Hours. Κάντε τις δοκιμές σας, δείτε και δύο στιγμιότυπα των δικών μας.

Εκτός των ωρών γραφείου ή κατά το σαββατοκύριακο, ο περιοριστικός μας κανόνας είναι απενεργοποιημένος. Βλέπουμε το μηχάνημα ενός bandwidth hog, ο οποίος κατεβάζει ένα torrent εκμεταλλευόμενος σχεδόν όλο το downstream bandwidth της σύνδεσής μας προς το Internet.

Εκτός των ωρών γραφείου ή κατά το σαββατοκύριακο, ο περιοριστικός μας κανόνας είναι απενεργοποιημένος. Βλέπουμε το μηχάνημα ενός bandwidth hog, ο οποίος κατεβάζει ένα torrent εκμεταλλευόμενος σχεδόν όλο το downstream bandwidth της σύνδεσής μας προς το Internet.

Ο ίδιος bandwidth hog επιχειρεί να κατεβάσει torrent κατά τις ώρες γραφείου, τις καθημερινές. Ο περιοριστικός μας κανόνας είναι ενεργοποιημένος και το μέγιστο download rate για τον φίλο μας δεν υπερβαίνει τα 256MBps, δηλαδή τα 2Mbps. Αν τολμήσει να παραπονεθεί στον υπεύθυνο δικτύου, θα έχει μια καλή ευκαιρία να ενημερωθεί για τη νέα πολιτική ορθής χρήσης.

Ο ίδιος bandwidth hog επιχειρεί να κατεβάσει torrent κατά τις ώρες γραφείου, τις καθημερινές. Ο περιοριστικός μας κανόνας είναι ενεργοποιημένος και το μέγιστο download rate για τον φίλο μας δεν υπερβαίνει τα 256MBps, δηλαδή τα 2Mbps. Αν τολμήσει να παραπονεθεί στον υπεύθυνο δικτύου, θα έχει μια καλή ευκαιρία να ενημερωθεί για τη νέα πολιτική ορθής χρήσης.

One Response to “Περιορισμός του bandwidth για τους αχόρταγους”

  1. Chris | 30/12/2015 at 11:03

    περιμένω τη συνέχεια του άρθρου:
    τι κάνουμε στην περίπτωση που ο διαχειριστής του δικτύου μας διαβάζει deltahacker – που μένει και που παρκάρει ο subZraw και άλλες ιστορίες..:-)

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

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