This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
start [2020/02/06 09:20] alex [Σωστή χρήση NAT/Masquerade] |
start [2023/12/09 14:08] (current) 10.2.19.13 [AWMN BGP filter] |
||
---|---|---|---|
Line 57: | Line 57: | ||
Ένα από τα βασικά εργαλεία, | Ένα από τα βασικά εργαλεία, | ||
- | ===== broken | + | ===== MikroTik |
**[[https:// | **[[https:// | ||
Line 133: | Line 133: | ||
Προαιρετικά εισάγουμε τα παρακάτω φίλτρα: | Προαιρετικά εισάγουμε τα παρακάτω φίλτρα: | ||
filter-in: none | filter-in: none | ||
- | filter-out: awmn | + | filter-out: awmn (μόνο αν το έχουμε ενεργό για κάθε wifi λινκ) |
| | ||
το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: | το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: | ||
+ | ===== MikroTik v7 C-class BGP aggregate ===== | ||
- | add action=discard chain=awmn | + | Στο MikroTik v7, το **C-class** ενός κόμβου **ΔΕΝ** ανακοινώνεται αυτόματα, |
- | | + | |
- | | + | Για να ξεπεραστεί το συγκεκριμένο πρόβλημα, |
+ | |||
+ | - Περνάμε ένα στατικό route του **C-class** δικτύου μας σαν **blackhole** | ||
+ | - Ενεργοποιούμε το **static** στο BGP, Output Redistribute | ||
+ | - Βεβαιώνουμε πως είναι ενεργοποιημένα, | ||
+ | |||
+ | Παράδειγμα: | ||
+ | |||
+ | εκτελούμε τα παρακάτω βήματα: | ||
+ | |||
+ | Routing --> BGP --> για κάθε νέα BGP σύνδεση ενεργοποιούμε στο Output Redistribute το static | ||
+ | |||
+ | IP --> Routes --> προσθέτουμε το --> Dst. Address 10.30.30.0/ | ||
+ | |||
+ | Υπάρχουν δυο ειδών **BGP** συνδέσεις. Η σύνδεση με απομακρυσμένο κόμβο λέγεται **eBGP**. Η σύνδεση με εσωτερικό router στο Local Area Network (LAN) λέγεται **iBGP**. | ||
+ | |||
+ | Το προτεινόμενο **AWMN** in/out φίλτρο μπαίνει **ΜΟΝΟ** στις **eBGP** --> στις εξωτερικές δηλαδή συνδέσεις/ | ||
+ | |||
+ | στις μεταξύ **iBGP** εσωτερικές συνδέσεις (LAN) του κόμβου, | ||
+ | |||
+ | οι σχετικές ρυθμίσεις από τερματικό/ | ||
+ | |||
+ | / | ||
+ | |||
+ | για κάθε **BGP** σύνδεση, | ||
+ | |||
+ | για παράδειγμα, | ||
+ | |||
+ | / | ||
+ | / | ||
+ | | ||
+ | / | ||
+ | / | ||
+ | |||
+ | στις παραπάνω εντολές προσθέτουμε αναλόγως τον τύπο σύνδεσης: | ||
+ | |||
+ | role=ebgp | ||
+ | |||
+ | role=ibgp | ||
+ | |||
+ | επιπλέον πρέπει να ορίσουμε (στις παραπάνω εντολές), | ||
+ | |||
+ | remote.address=10.30.30.254/32 | ||
+ | local.address=10.30.30.253 | ||
+ | |||
+ | σαν router id προτιμούμε (αν υπάρχει) την lan/ | ||
+ | |||
+ | id=10.30.30.1 | ||
+ | |||
+ | και η τελική εντολή: | ||
+ | |||
+ | / | ||
+ | |||
+ | *** * Προσοχή ** ! στο τελευταίο βήμα θα πρέπει πάντα να βάζουμε το δίκτυό μας με το **/24** στο τέλος, ανεξάρτητα με το πως το έχουμε σπάσει σε μικρότερα | ||
+ | |||
+ | Σε περιπτώσεις προβλημάτων ασυμμετρίας στο εσωτερικό ενός κόμβου, | ||
+ | |||
+ | | ||
+ | |||
+ | // | ||
+ | |||
+ | ===== MikroTik terminal setup for SupperQuagga ===== | ||
+ | |||
+ | /routing bgp peer add remote-as=22128 remote-address=10.2.146.10 multihop=yes passive=yes name=spq hold-time=180s keepalive-time=60s | ||
+ | |||
+ | /routing bgp peer print | ||
+ | |||
+ | για **v7**: | ||
+ | |||
+ | / | ||
+ | |||
+ | / | ||
| | ||
- | Στην τοποθεσία Routing--> | + | Παράδειγμα: κόμβος 3298, δίκτυο 10.2.19.0/ |
- | το παραπάνω φίλτρο καταπολεμά σε ένα ικανοποιητικό βαθμό το μεγαλύτερο μέρος των | + | **! ! !** --> |
+ | ==== MikroTik BGP log filter ==== | ||
+ | Σε περίπτωση | ||
- | **για quagga**: | + | /system logging set [find where topics=" |
+ | /system logging set [find where topics=" | ||
+ | ===== Quagga setup for SupperQuagga ===== | ||
neighbor 10.2.146.10 remote-as 22128 | neighbor 10.2.146.10 remote-as 22128 | ||
neighbor 10.2.146.10 ebgp-multihop | neighbor 10.2.146.10 ebgp-multihop | ||
Line 156: | Line 232: | ||
ip prefix-list awmn-null seq 20 deny any | ip prefix-list awmn-null seq 20 deny any | ||
| | ||
- | και **για bird:** | + | ===== Bird setup for SupperQuagga ===== |
protocol bgp { | protocol bgp { | ||
export filter awmn; | export filter awmn; | ||
Line 180: | Line 256: | ||
αν καταφέρουμε να χαρτογραφήσουμε πιο ορθά το BGP θα έχουμε και μια πιο έγκυρη εικόνα με τους πραγματικούς κόμβους ραχοκοκαλιάς του AWMN | αν καταφέρουμε να χαρτογραφήσουμε πιο ορθά το BGP θα έχουμε και μια πιο έγκυρη εικόνα με τους πραγματικούς κόμβους ραχοκοκαλιάς του AWMN | ||
- | * Μια πολύ ενδιαφέρουσα και χρήσιμη υπηρεσία, | + | * Μια πολύ ενδιαφέρουσα και χρήσιμη υπηρεσία, |
- | + | ||
- | ===== Σωστή χρήση NAT/ | + | |
- | + | ||
- | src=!10.0.0.0/ | + | |
- | src=10.0.0.0/ | + | |
- | + | ||
- | στον δεύτερο (τελευταίο) κανόνα, | + | |
===== Μερικές οδηγίες χρήσης του εργαλείου ===== | ===== Μερικές οδηγίες χρήσης του εργαλείου ===== | ||
Line 195: | Line 264: | ||
ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP). | ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP). | ||
+ | |||
+ | |||
+ | ===== eBGP & iBGP ===== | ||
+ | |||
+ | το **BGP** έχει δυο κατηγορίες: | ||
+ | |||
+ | το **eBGP** σημαίνει external **BGP** και είναι αυτό που συνδέουμε τον κόμβο μας με άλλους απομακρυσμένους κόμβους (τα **BB** λινκ που λέμε). σε αυτού του είδους τις συνδέσεις **και ΜΟΝΟ** περνάμε το προτεινόμενο **awmn BGP** φιλτρο. | ||
+ | |||
+ | το **iBGP** σημαίνει internal **BGP** και είναι αυτό που συνδέουμε δικούς μας εσωτερικούς **router** στον **ίδιο** κόμβο μεταξύ τους | ||
+ | |||
+ | δηλαδή για παράδειγμα, | ||
+ | |||
+ | σε αυτές τις εσωτερικές **iBGP** συνδέσεις ΔΕΝ θα πρέπει να βάζουμε **κανένα** φίλτρο, | ||
+ | |||
+ | επιπλέον, | ||
+ | |||
+ | ==== iBGP problem explained ==== | ||
+ | το πρόβλημα με το **iBGP** έχει να κάνει με το σπάσιμο του τοπικού **C-class** σε μικρότερα υποδίκτυα τα οποία χρησιμοποιούμε για τις **WAN** συνδέσεις (**BB** link). σε αυτές τις περιπτώσεις, | ||
+ | |||
+ | επιπλέον, | ||
+ | |||
+ | το **awmn BGP** φίλτρο το χρησιμοποιούμε **ΜΟΝΟ** σε **eBGP** συνδέσεις, | ||
+ | === iBGP troubleshoot === | ||
+ | ένας απλός & σίγουρος τρόπος για να εντοπίσουμε αν υπάρχει πρόβλημα σωστής **iBGP** επικοινωνίας σε έναν κόμβο που τρέχει πάνω από έναν **BGP** speaker είναι, να κάνουμε **ping** σε ένα **IP** ενός **/30** ή **/29** υποδικτύου που έχουμε κόψει από το δικό μας **C-class** για χρήση **wan/BB**, από τους άλλους τοπικούς **BGP** speakers του τοπικού μας δικτύου (αυτούς που **ΔΕΝ** έχουν σε **WAN** σύνδεση αυτό το **wan/BB** υποδίκτυο αλλά οφείλουν να το γνωρίζουν. αν το **ping** λειτουργεί, | ||
+ | ===== AWMN BGP filter ===== | ||
+ | |||
+ | Ακολουθεί το προτεινόμενο φίλτρο καλής χρήσης & προστασίας του **BGP** για το **AWMN** το οποίο επιβάλεται να έχουμε σε κάθε BGP με ασυρματική ζεύξη/ | ||
+ | |||
+ | Ανοίγουμε ένα Terminal δίνουμε τις παρακάτω εντολές: | ||
+ | /routing filter | ||
+ | add action=discard chain=awmn bgp-as-path-length=!0-28 | ||
+ | add action=accept chain=awmn prefix=10.0.0.0/ | ||
+ | add action=accept chain=awmn prefix=10.0.0.0/ | ||
+ | add action=discard chain=awmn | ||
+ | | ||
+ | για **v7**: | ||
+ | |||
+ | / | ||
+ | / | ||
+ | |||
+ | * **Ενημέρωση 9 Δεκέμβρη 2023** * | ||
+ | |||
+ | * * * {!} * * * Οι παραπάνω αρχικοί κανόνες δεν δείχνουν να δουλεύουν για την **v7** . Οι παρακάτω **ενημερωμένοι** κανόνες δοκιμάστηκαν και λειτουργούν. θα πρέπει να γίνει ένας διαχωρισμός σε δυο κανόνες, | ||
+ | |||
+ | /routing filter rule add chain=awmn-in rule=" | ||
+ | /routing filter rule add chain=awmn-out rule=" | ||
+ | | ||
+ | Στην τοποθεσία Routing--> | ||
+ | |||
+ | Το παραπάνω φίλτρο αποκλείει τις μαύρες τρύπες που ακυρώνουν τον δυναμικό, | ||
+ | |||
+ | ===== AWMN NAT/ | ||
+ | |||
+ | ** * * * Προσοχή * * * ** στην χρήση του **NAT/ | ||
+ | |||
+ | στο **IP**--> | ||
+ | |||
+ | αν το IP/ | ||
+ | src=!10.0.0.0/ | ||
+ | | ||
+ | αν έχουμε 10ρι που θέλουμε να κάνουμε NAT τότε ο κανόνας είναι: | ||
+ | src=10.0.0.0/ | ||
+ | | ||
+ | ο πρώτος κανόνας εξασφαλίζει το NAT σε δίκτυο/ | ||
+ | |||
+ | ο δεύτερος κανόνας εξασφαλίζει το NAT σε δίκτυο/ | ||
+ | |||
+ | στο **src** είναι **καλό & σωστότερο** να ορίζονται τα συγκεκριμένα δίκτυα που μας αφορούν. | ||
+ | |||
+ | Αν δεν υπάρχει η δυνατότητα να καθοριστούν συγκεκριμένα τα δίκτυα src=, τότε οι παραπάνω δυο γενικοί κανόνες, | ||
+ | ===== cloud.mikrotik.com DNS Storm ===== | ||
+ | |||
+ | Σε πολλές περιπτώσεις, | ||
+ | |||
+ | 12: | ||
+ | 12: | ||
+ | 12: | ||
+ | 12: | ||
+ | 12: | ||
+ | 12: | ||
+ | |||
+ | Κάποιες προτεινόμενες λύσεις στο συγκεκριμένο πρόβλημα είναι οι ακόλουθες: | ||
+ | |||
+ | - Απενεργοποίηση [[https:// | ||
+ | - Απενεργοποίηση [[https:// | ||
+ | - Απενεργοποίηση [[https:// | ||
+ | - Απενεργοποίηση [[https:// | ||
+ | |||
+ | ===== Mikrotik DNS Setup ===== | ||
+ | |||
+ | /ip dns set allow-remote-requests=yes | ||
+ | |||
+ | Το παρακάτω, | ||
+ | |||
+ | /ip dns set servers=8.8.8.8, | ||
+ | /ip dns static add forward-to=10.19.143.12 regexp=" | ||
+ | |||
+ | Προσθέτουμε τα ονόματα του κόμβου μας (για παράδειγμα, | ||
+ | | ||
+ | /ip dns static add name=router.soleo.awmn address=10.38.128.5 | ||
+ | | ||
+ | για τις wifi (BB link) συνδέσεις, | ||
+ | | ||
+ | /ip dns static add name=gw-makofo.soleo.awmn address=10.38.128.249 | ||
+ | /ip dns static add name=gw-soleo.makofo.awmn address=10.38.128.250 | ||
+ | | ||
+ | **Προσοχή**, | ||
+ | |||
+ | Αν θέλουμε να δώσουμε **επιπλέον** ονομασίες σε μια **IP**, ο σωστός & προτεινόμενος τρόπος είναι ο πιο κάτω: | ||
+ | |||
+ | /ip dns static add name=alias.soleo.awmn type=CNAME cname=router.soleo.awmn | ||
+ | | ||
+ | με τον παραπάνω τρόπο, όταν δίνουμε (για επίλυση σε όνομα) μια **IP**, για παράδειγμα: | ||
+ | |||
+ | όλες οι επιπλέον ονομασίες ορισμένες σαν **CNAME** θα αντιστοιχούν στον **router.soleo.awmn** δηλαδή --> **10.38.128.5** | ||
+ | | ||
+ | ===== Asymmetric routing & UDP ===== | ||
+ | |||
+ | η ανάπτυξη του **AWMN** δικτύου είναι βασισμένη σε κόμβους με πολλαπλές συνδέσεις, | ||
+ | |||
+ | There is nothing tinc can do here. Either make sure you don't do | ||
+ | asymetric routing, or change your firewall rules to not do stateful | ||
+ | filtering of TCP connections | ||
+ | | ||
+ | ανατρέχοντας στις [[https:// | ||
+ | |||
+ | /ip firewall filter | ||
+ | add chain=input connection-state=invalid action=drop comment=" | ||
+ | add chain=input connection-state=established, | ||
+ | ** | ||
+ | //__Such a rule set must not be applied on routers with asymmetric routing, because asymmetrically routed packets may be considered invalid and dropped__// | ||
+ | |||
+ | οπότε αν θέλουμε το **DNS** που τρέχουμε να λειτουργεί σε **όλο** το δίκτυο, | ||
+ | |||
+ | /ip firewall filter | ||
+ | del chain=input connection-state=established, | ||
+ | del chain=input connection-state=invalid action=drop comment=" | ||
+ | | ||
+ | το παρακάτω παράδειγμα δείχνει καθαρά το πρόβλημα: | ||
+ | |||
+ | In BGP | ||
+ | 5 7413 8345 7430 9936 3298 | ||
+ | 5 7413 11087 7430 9936 3298 | ||
+ | | ||
+ | ο κόμβος 7413 μπορεί να πάρει udp/dns αποκρίσεις & στην περίπτωση που ο κόμβος 3298 είχε stateful firewall, μια και η εισερχόμενη διαδρομή είναι ίδια με την εξερχόμενη (δηλαδή μέσα από τον κόμβο 9936) | ||
+ | |||
+ | ο κόμβος 3298 όμως ΔΕΝ μπορεί να λάβει udp/dns αποκρίσεις διότι το stateful firewall του κόμβου 7413 κόβει κάθε connectionless (udp) κίνηση που έχει ασυμμετρία. στην προκειμένη ο 3298 διαλέγει την συγκεκριμένη διαδρομή προς 7413 | ||
+ | |||
+ | 3298 9936 7430 8345 7413 | ||
+ | | ||
+ | ενώ ο κόμβος 7413 την διαδρομή: | ||
+ | |||
+ | 7413 11087 7430 9936 3298 | ||
+ | | ||
+ | ===== BGPmap Tips & Tricks ===== | ||
+ | | ||
+ | ==== 3D map @ AWMN ==== | ||
+ | |||
+ | - πάμε στο http:// | ||
+ | - στο δεξί δεξί menu κάτω εκεί που λέει Search Node βάζουμε (παράδειγμα) virtual & πατάμε enter | ||
+ | - θα μας ανοίξει από κάτω (δεξιά) ένα menu, στο κάτω μέρος πατάμε το View node in 3D mode | ||
+ | - κάτω δεξιά πατάμε την υδρόγειο για να μας ανοίξει το 3D | ||
+ | - η ρόδα του ποντικιού, | ||
+ | - το αριστερό κουμπί του ποντικιού ελέγχει την οριζόντια πλοήγηση | ||
+ | - το αριστερό κουμπί του ποντικιού με το Ctrl πατημένο ελέγχει την κάθετη πλοήγηση | ||
+ | |||
+ | //happy 3D flying// | ||
+ | |||
+ | ==== BGP Trace ==== | ||
+ | |||
+ | - στο δεξί παράθυρο (Control center), πηγαίνουμε στο Trace Route | ||
+ | - βάζουμε είτε με όνομα κόμβου είτε με αριθμό AS τους κόμβους που μας ενδιαφέρει να εξετάσουμε | ||
+ | - πατάμε την ένδειξη Show route | ||
+ | |||
+ | η παραπάνω διαδικασία: | ||
+ | |||
+ | - θα απαριθμήσει τους κόμβους από τους οποίους περνάει η σύνδεση αυτών των δυο κόμβων | ||
+ | - θα αποτυπώσει πάνω στον χάρτη με μπλε χρώμα τις παραπάνω διαδρομές | ||
+ | - στο δεξί μενού με την ένδειξη Possible Route(s), θα εμφανίσει την διαδρομή με όλα τα AS (κόμβους) που μεσολαβούν | ||
+ | |||
+ | πατώντας σε κάθε AS κόμβο, η πλοήγηση μεταφέρεται αυτόματα στον συγκεκριμένο κόμβο για περαιτέρω εξέταση | ||
+ |