SupperQuagga is an attempt to ease the process of BGP troubleshooting with live multi-node passive peering, offering accurate network mapping, and a comprehensive variety of bgp forensics tools around the AWMN routing.
SupperQuagga is further powering BGPmap, BGPnms & AWMN Dancing BGP.
AWMN, established back in 2002 is a small Internet that is run & managed by its users only. No commercial companies or government/academic foundations are involved. It's a purely amateur initiative, ideal for, besides the zero-cost connectivity, experimenting & learning playground. It also serves as a magnet in maintaining a verity of different people together.
The audience & the community of this initiative, is exclusively Hellenic thereof further language use will be switched to Greek.
Το AWMN ξεκίνησε το 2002 και είναι ένα μικρό Internet αποτελούμενο από τους χρήστες του και μόνο. Δεν υπάρχουν εμπορικοί, κρατικοί ή ακαδιμαικοί οργανισμοί, μεσάζοντες ή εταιρίες. Είναι ένα καθαρά ερασιτεχνικό εγχείρημα, ιδανικό, πέρα από το μηδενικό κόστος διασυνδεσιμότητας, για πειραματισμό και εκμάθηση. Επιπλέον συγκεντρώνει & συσπειρώνει ένα μεγάλο εύρος διαφορετικών ανθρώπων.
Οι παρακάτω οδηγίες δεν ισχύουν πλέον. αποτελούν αρχειακό υλικό.
To: awmn@googlegroups.com Date: 2016-01-14 08:41
supper quagga: προσπάθεια εντοπισμού φαντασμάτων και λανθασμένων ρυθμίσεων στο BGP του AWMN, άλλη μια νέα υπηρεσία powered by http://www.stats.awmn & http://www.routers.awmn/
για μπρίκι:
για quagga:
ip prefix-list awmn-null seq 20 deny any neighbor 10.2.19.3 remote-as 3298 neighbor 10.2.19.3 ebgp-multihop neighbor 10.2.19.3 prefix-list awmn-null in
στείλε μου IP & AS από τους router που θα συμμετάσχουν στην supper quagga να τους προσθέσω
καμιά ευαίσθητη εσωτερική πληροφορία δεν “διαρρέει” αφού ότι ανακοινώνεις στο BGP στο AWMN απλά το περνάς και στην supper quagga και απαγορεύεις να σου περάσει τίποτα πίσω !!
προώθησέ το παντού, είναι για καλό σκοπό !! όσοι περισσότεροι τόσο καλύτερα !!
Αν και οι περισσότεροι εναπομείναντες του AWMN θεωρούν πως η MikroTik βοήθησε το δίκτυο στην εξάπλωσή του, στην ουσία το τίναξε στον αέρα. Εξουδετέρωσε το αρχικό πνεύμα συνεργασίας με οδηγούς γύρω από ανοιχτές πλατφόρμες, αρχιτεκτονικές και λογισμικό και ώθησε τον κόσμο σε black boxes τα οποία πολλές φορές είχαν προβλήματα που όπως θα δούμε πήραν πάνω από 4-5 χρόνια να λυθούν, ενώ άλλα παραμένουν και καταδυναστεύουν το δίκτυο μέχρι και σήμερα.
Το μεγαλύτερο πρόβλημα, το οποίο παραμένει μέχρι σήμερα, έχει να κάνει με τον τρόπο που η MikroTik διαχειρίζεται το IP routing ειδικά στο BGP που χρησιμοποιούμε στο AWMN. Αυτό το πρόβλημα δημιούργησε τουλάχιστον τρία με τέσσερα blackout στην δρομολόγηση με το BGP να σκάει από άκρη σε άκρη σε όλο το δίκτυο. Σήμερα παραμένει να διατηρεί διαδρομές οι οποίες δεν είναι ενεργές και τις οποίες αποκαλούμε φαντάσματα.
το Ιστορικό ξεκινά από το 2007. Στο forum της MikroTik υπάρχει μια ενότητα που ξεκινά το 2011 και η οποία μετά από τρία χρόνια, το 2014 δεν έχει λυθεί. Το πρόβλημα μεταφέρεται σε άλλη ενότητα η οποία ξεκινά το 2013 και συνεχίζεται μέχρι το 2019 χωρίς ακόμη να έχουν λυθεί τα αναφερόμενα προβλήματα.
Ένα από τα βασικά εργαλεία, μεταξύ άλλων, που παρέχει η SupperQuagga είναι ο εντοπισμός της πηγής δημιουργίας τέτοιων φαντασμάτων με το bgp ghost-detector.
gustkiller Tue Dec 20, 2011 11:57 pm Hi, Every now and them we got that problem. Today another AS network engineer called me becouse his IP prefix couldnt reach our prefixes. After troubleshooting he told me that they lost they connection in a national wide IXP and when doing a traceroute from our bgp router, the next hop showed was our IXP ip address. After checking the routes, we're receiving their routes via another service provider but RouterOS were trying to get to them via a cached route that doesnt even exists anymore. To fix the problem we have to disable the IXP interface on our router and them reenable it. After that RouterOS finnaly forgot the route and them everything started to work. Anyone more having that problem? Is there any command to clear routing cache? Thanks!
…
Pengu1n Mon Oct 13, 2014 11:25 am Is there any news about fixing this bug? Still have problems with CCR1016-12G and RB751G-2HnD on 6.20 We are using OSPF and IPSEC.
ujin Tue Oct 22, 2013 2:13 pm The problem is following: The oldest entries are not flushed from cache. During one day we got: /ip route cache print cache-size: 52442 max-cache-size: 65536 This bug is observed only on OS version 6.x. OS version 5.x did not have such issue. Please provide workaround HOW TO FLUSH CACHE.
…
cgood Fri Mar 15, 2019 12:05 pm >> Currently it is known that OVPN interface reconnects are responsible for route cache leaks. Hello, how to fix this issue? Mikrotik CHR -> ip route cache full 512k .. OVPN/L2TP server
η Supper Quagga ή αλλιώς: BGP αξονικός τομογράφος του AWMN, γεννήθηκε ως ανάγκη να έχουμε μια καλύτερη εικόνα του τι πραγματικά συμβαίνει στην δρομολόγηση BGP του δικτύου μας.
Αποτελεί ένα επιπλέον εργαλείο που στόχο έχει να βοηθήσει στον εντοπισμό λανθασμένων ρυθμίσεων η άλλων προβλημάτων στο BGP που όλοι τρέχουμε και περνάει από τους κόμβους μας.
τα στοιχεία της Supper Quagga είναι:
για MikroTik, δημιουργούμε ένα νέο peer στο BGP με την ονομασία supperquagga με τα ακόλουθα στοιχεία:
IP: 10.2.146.10 AS: 22128 multihop
είναι σημαντικό να επιλεχθεί το πεδίο multihop. !!–> προσοχή το συγκεκριμένο πεδίο πρέπει να είναι ενεργό ΜΟΝΟ για τον peer supperquagga
Προαιρετικά εισάγουμε τα παρακάτω φίλτρα: !!–> δεν αποτελεί απαραίτητη προϋπόθεση
filter-in: none filter-out: awmn (μόνο αν το έχουμε ενεργό για κάθε wifi λινκ)
το φίλτρο που έχει προταθεί σαν RFC, το οποίο μπορεί να χρησιμοποιηθεί από όλες τις Ελληνικές ασύρματες κοινότητες που χρησιμοποιούν BGP πάνω στο δίκτυο 10.0.0.0/8 και που καλό είναι να εφαρμόζεται από όλους τους κόμβους κορμού σε κάθε εισερχόμενη και εξερχόμενη peer BGP σύνδεση: δεν αποτελεί απαραίτητη προϋπόθεση
Στο MikroTik v7, το C-class ενός κόμβου ΔΕΝ ανακοινώνεται αυτόματα, όταν το έχουμε χωρίσει σε μικρότερα subnets. Η σχετική αναφορά της Mikrotik βρίσκεται εδώ.
Για να ξεπεραστεί το συγκεκριμένο πρόβλημα, θα πρέπει να ακολουθηθούν τα παρακάτω βήματα:
Παράδειγμα: έστω πως το C-class δίκτυό μας είναι το: 10.30.30.0/24
εκτελούμε τα παρακάτω βήματα:
Routing --> BGP --> για κάθε νέα BGP σύνδεση ενεργοποιούμε στο Output Redistribute το static IP --> Routes --> προσθέτουμε το --> Dst. Address 10.30.30.0/24 & ενεργοποιούμε ΜΟΝΟ το Blackhole
Υπάρχουν δυο ειδών BGP συνδέσεις. Η σύνδεση με απομακρυσμένο κόμβο λέγεται eBGP. Η σύνδεση με εσωτερικό router στο Local Area Network (LAN) λέγεται iBGP.
Το προτεινόμενο AWMN in/out φίλτρο μπαίνει ΜΟΝΟ στις eBGP –> στις εξωτερικές δηλαδή συνδέσεις/λινκ του κόμβου.
στις μεταξύ iBGP εσωτερικές συνδέσεις (LAN) του κόμβου, δεν περνάμε ΚΑΝΕΝΑ φίλτρο.
οι σχετικές ρυθμίσεις από τερματικό/ssh είναι:
/routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=0
για κάθε BGP σύνδεση, θα πρέπει να ορίσουμε τα παραπάνω αλλάζοντας το numbers=
για παράδειγμα, αν έχουμε ένα router με πέντε (5) BGP συνδέσεις, θα πρέπει να δώσουμε την εντολή στην παρακάτω μορφή:
/routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=0 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=1 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=2 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=3 /routing/bgp/connection/set output.redistribute=static,bgp hold-time=30s keepalive-time=10s numbers=4
στις παραπάνω εντολές προσθέτουμε αναλόγως τον τύπο σύνδεσης:
role=ebgp
role=ibgp
επιπλέον πρέπει να ορίσουμε (στις παραπάνω εντολές), για κάθε σύνδεση, τα σχετικά παρακάτω πεδία:
remote.address=10.30.30.254/32 local.address=10.30.30.253
σαν router id προτιμούμε (αν υπάρχει) την lan/ethernet IP του router:
id=10.30.30.1
και η τελική εντολή:
/ip/route/add blackhole dst-address=10.30.30.0/24
* * Προσοχή ! στο τελευταίο βήμα θα πρέπει πάντα να βάζουμε το δίκτυό μας με το /24 στο τέλος, ανεξάρτητα με το πως το έχουμε σπάσει σε μικρότερα
Σε περιπτώσεις προβλημάτων ασυμμετρίας στο εσωτερικό ενός κόμβου, βοηθάει στο μεταξύ iBGP τοπικών router, να ενεργοποιηθεί η επιλογή:
nexthop-choice=force-self
Ευχαριστώ τον Δημήτρη (dgi) για την πρόσβαση σε MikroTik v7 για τις σχετικές δοκιμές
/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/bgp/connection add remote.as=22128 as=local_awmn_AS local.address=local_lan_ethernet_ip local.role=ebgp remote.address=10.2.146.10 multihop=yes listen=yes name=spq /routing/bgp/connection/print
Παράδειγμα: κόμβος 3298, δίκτυο 10.2.19.0/24. as=3298 local.address=10.2.19.65
! ! ! –> σαν router id προτιμούμε (αν υπάρχει) την lan/ethernet IP του router
Σε περίπτωση που δεν θέλουμε να γεμίζουν τα logs με bgp μυνήματα από τη SupperQuagga, οι παρακάτω εντολές φιλτράρουν τα συγκεκριμένα μυνήματα από τα log
/system logging set [find where topics="error"] topics="error,!bgp" /system logging set [find where topics="info"] topics="info,!bgp"
neighbor 10.2.146.10 remote-as 22128 neighbor 10.2.146.10 ebgp-multihop neighbor 10.2.146.10 prefix-list awmn-null in neighbor 10.2.146.10 prefix-list awmn-bgp out ! ip prefix-list awmn-bgp seq 10 permit 10.0.0.0/8 ge 9 le 24 ip prefix-list awmn-bgp seq 15 permit 10.0.0.0/15 le 32 ip prefix-list awmn-bgp seq 20 deny any ip prefix-list awmn-null seq 20 deny any
protocol bgp { export filter awmn; import none; local as 3298; neighbor 10.2.146.10 as 22128; multihop; }
η διαδικασία ολοκληρώνεται με ένα email στο alex_παπάκι_ozo.com με το IP και το AS του κάθε ρούτερ που πρόκειται να συμμετάσχει στην SupperQuagga.
Περί Ασφάλειας στην SupperQuagga αποστέλλεται ακριβώς και μόνο η ίδια πληροφορία με αυτή που στέλνεται προς τους γειτονικούς κόμβους για το AWMN. Αντίστοιχα η SupperQuagga έχει φίλτρα στα εισερχόμενα για αποκλειστικά και μόνο δίκτυα AWMN. Επιπλέον δεν στέλνει απολύτως καμία πληροφορία προς τις συνδέσεις της, κάτι που διασφαλίζεται και με ένα προαιρετικό φίλτρο none στο IN του BGP μαζί της.
Είναι τελείως ακίνδυνη χωρίς να καταναλώνει επιπλέον πόρους στο σύστημα που συμμετέχει σε αυτήν.
στατιστικά από την SPQ για το πανελλαδικό BGP nmsBGP.
Η Supper Quagga τρέχει την έκδοση quagga-1.2.4 η οποία αναβαθμίζεται σε κάθε νέα έκδοση όταν αυτή είναι διαθέσιμη.
Τα εργαλεία της SupperQuagga δίνουν την δυνατότητα για μια πιο εύκολη και σε βάθος ανάλυση σχετικά με το BGP που κυκλοφορεί στις διασυνδεδεμένες μεταξύ τους ασύρματες κοινότητες. Είναι ένα πολυ-εργαλείο που μπορεί μαθησιακά να βοηθήσει στην καλύτερη κατανόηση του πως ακριβώς δουλεύει το BGP, τα προβλήματα και τις δυνατότητες που έχει, πάνω σε ένα πραγματικό και ζωντανό δίκτυο.
αν καταφέρουμε να χαρτογραφήσουμε πιο ορθά το BGP θα έχουμε και μια πιο έγκυρη εικόνα με τους πραγματικούς κόμβους ραχοκοκαλιάς του AWMN
μέσα από το γραφικό περιβάλλον της Supper Quagga μπορούμε να έχουμε μια γρήγορη και εύκολη εικόνα με το ποιοι κόμβοι ανεβοκατεβαίνουν πολλές φορές μέσα στην ημέρα δημιουργώντας πιθανά προβλήματα στην δρομολόγηση.
αυτό που παρατηρεί κάποιος εξετάζοντας το φαινόμενο των flaps στο BGP είναι ότι συνήθως πρόκειται για τερματικούς κόμβους που δεν επηρεάζουν τη γενικότερη δρομολόγηση του δικτύου (απλά ρυπαίνουν το BGP με την προβληματική συμπεριφορά τους).
ένα ερώτημα προβληματισμός που εγείρεται είναι γιατί αυτοί οι τερματικοί κόμβοι να στέλνουν BGP στην δρομολόγηση και να μην λειτουργούν απλά με ένα static route. Αυτό εξάλλου είναι ορθά και εκτός προδιαγραφών AWMN (δηλαδή τερματικοί κόμβοι & BGP).
το BGP έχει δυο κατηγορίες: eBGP & iBGP
το eBGP σημαίνει external BGP και είναι αυτό που συνδέουμε τον κόμβο μας με άλλους απομακρυσμένους κόμβους (τα BB λινκ που λέμε). σε αυτού του είδους τις συνδέσεις και ΜΟΝΟ περνάμε το προτεινόμενο awmn BGP φιλτρο.
το iBGP σημαίνει internal BGP και είναι αυτό που συνδέουμε δικούς μας εσωτερικούς router στον ίδιο κόμβο μεταξύ τους
δηλαδή για παράδειγμα, έχουμε ένα alix, ένα rb433AH & ένα groove και τρέχουμε σε κάθε ένα από αυτά BGP τα οποία συνδέουμε μεταξύ τους (αυτή η μεταξύ τους τοπική σύνδεση την αποκαλούμε iBGP –> εσωτερική, internal)
σε αυτές τις εσωτερικές iBGP συνδέσεις ΔΕΝ θα πρέπει να βάζουμε κανένα φίλτρο, ούτε το awmn BGP φίλτρο
επιπλέον, καλό είναι να ενεργοποιούμε στο BGP την επιλογή Redistribute connected & client-to-client-reflection
το πρόβλημα με το iBGP έχει να κάνει με το σπάσιμο του τοπικού C-class σε μικρότερα υποδίκτυα τα οποία χρησιμοποιούμε για τις WAN συνδέσεις (BB link). σε αυτές τις περιπτώσεις, όταν έχουμε πάνω από εναν κεντρικό BGP speaker στον κόμβο (LAN), συνήθως οι άλλοι BGP routers αγνοούν την ύπαρξη του τοπικού wan/BB υποδικτύου. παλιά, αυτό αντιμετωπίζονταν με την παράλληλη χρήση ενός IGP routing όπως το OSPF, RIP ή & static routes. πλέον, οι σύγχρονες BGP εκδόσεις, έχουν την δυνατότητα να ανακοινώνουν αυτά τα εσωτερικά υποδίκτυα, αρκεί να μην φιλτράρεται η συγκεκριμένη πληροφορία. οπότε σε αυτές τις περιπτώσεις, δεν θα πρέπει να εισάγουμε κανένα φίλτρο μεταξύ των τοπικών BGP συνδέσεων στο LAN ενός κόμβου.
επιπλέον, στους router πάνω στο LAN μεταξύ τους, ορίζουμε το next-hop σαν force-self & ΟΧΙ default
το awmn BGP φίλτρο το χρησιμοποιούμε ΜΟΝΟ σε eBGP συνδέσεις, αυτές με άλλους απομακρυσμένους κόμβους, ώστε να μην ανακοινώνουμε στο γενικό BGP υποδίκτυα μικρότερα του C-class, και γενικά να θωρακίζουμε/φιλτράρουμε την πληροφορία του BGP από λανθασμένες ρυθμίσεις ή κακόβουλες ενέργειες.
ένας απλός & σίγουρος τρόπος για να εντοπίσουμε αν υπάρχει πρόβλημα σωστής iBGP επικοινωνίας σε έναν κόμβο που τρέχει πάνω από έναν BGP speaker είναι, να κάνουμε ping σε ένα IP ενός /30 ή /29 υποδικτύου που έχουμε κόψει από το δικό μας C-class για χρήση wan/BB, από τους άλλους τοπικούς BGP speakers του τοπικού μας δικτύου (αυτούς που ΔΕΝ έχουν σε WAN σύνδεση αυτό το wan/BB υποδίκτυο αλλά οφείλουν να το γνωρίζουν. αν το ping λειτουργεί, τότε δεν υπάρχει το iBGP πρόβλημα. σε διαφορετική περίπτωση, το πρόβλημα υπάρχει & θα πρέπει να διερευνηθεί & λυθεί.
Ακολουθεί το προτεινόμενο φίλτρο καλής χρήσης & προστασίας του 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/8 prefix-length=24 add action=accept chain=awmn prefix=10.0.0.0/15 prefix-length=32 add action=discard chain=awmn
για v7:
/routing filter rule add chain=awmn rule="if (dst in 10.0.0.0/8 && dst-len==24 && bgp-path-len<27) { accept; }" /routing filter rule add chain=awmn rule="if (dst in 10.0.0.0/15 && dst-len==32 && bgp-path-len<27) { accept; }"
* Ενημέρωση 9 Δεκέμβρη 2023 *
* * * {!} * * * Οι παραπάνω αρχικοί κανόνες δεν δείχνουν να δουλεύουν για την v7 . Οι παρακάτω ενημερωμένοι κανόνες δοκιμάστηκαν και λειτουργούν. θα πρέπει να γίνει ένας διαχωρισμός σε δυο κανόνες, awmn-in & awmn-out. Επιπλέον αφαιρούμε το φίλτρο anycast, μια υπηρεσία που ήταν πειραματική στις μέρες του 2005-2009 ενώ ποτέ δεν δούλεψε ικανοποιητικά. Σήμερα, εν έτει 2023, η αποδοχή της στα φίλτρα αποτελεί κενό ασφάλειας, οπότε και αφαιρείται.
/routing filter rule add chain=awmn-in rule="if (dst in 10.0.0.0/8 && dst-len==24 && bgp-path-len<27) { accept; }" /routing filter rule add chain=awmn-out rule="if (dst in 10.0.0.0/8 && dst-len==24) { accept; }"
Στην τοποθεσία Routing–>BGP–>Peers, σε κάθε ασυρματική σύνδεση, όχι με τους τοπικούς μας άλλους router, επιλέγουμε για φίλτρο IN και OUT την επιλογή awmn.
Το παραπάνω φίλτρο αποκλείει τις μαύρες τρύπες που ακυρώνουν τον δυναμικό, ζωντανό & διάφανο χαρακτήρα του BGP, καταπολεμά σε ένα ικανοποιητικό βαθμό το μεγαλύτερο μέρος των φαντασμάτων, ενώ προστατεύει & θωρακίζει από κακόβουλες ενέργειες ή ακούσιες λανθασμένες ρυθμίσεις. Δεν αποτελεί απαραίτητη προϋπόθεση αλλά η χρήση του συνιστάται.
* * * Προσοχή * * * στην χρήση του NAT/Masquerade
στο IP–>Firewall–>NAT
αν το IP/δύκτιο που θέλουμε να κάνουμε NAT δεν είναι 10ρι τότε ο κανόνας είναι:
src=!10.0.0.0/8 (dst=0.0.0.0/0 ή κενό)
αν έχουμε 10ρι που θέλουμε να κάνουμε NAT τότε ο κανόνας είναι:
src=10.0.0.0/8 dst=!10.0.0.0/8
ο πρώτος κανόνας εξασφαλίζει το NAT σε δίκτυο/IP που ΔΕΝ ανήκει σε 10ρι να γίνεται NAT προς οποιοδίποτε δίκτυο.
ο δεύτερος κανόνας εξασφαλίζει το NAT σε δίκτυο/IP που ανήκει σε 10ρι & θέλουμε να ΜΗΝ γίνεται NAT όταν απευθύνεται σε 10ρι δίκτυο, αλλά να γίνεται NAT όταν θέλει να πάει σε ΟΧΙ 10ρι δίκτυο.
στο src είναι καλό & σωστότερο να ορίζονται τα συγκεκριμένα δίκτυα που μας αφορούν.
Αν δεν υπάρχει η δυνατότητα να καθοριστούν συγκεκριμένα τα δίκτυα src=, τότε οι παραπάνω δυο γενικοί κανόνες, εξασφαλίζουν την απρόσκοπτη & σωστή διεύλευση της 10.0.0.0/8 κίνησης.
Σε πολλές περιπτώσεις, MikroTik δρομολογητές με default ρυθμίσεις, δημιουργούν πολύ ενοχλήτικές & άχρηστες καταγίδες σε χρήση DNS
12:32:38.113564 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:38.113618 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52) 12:32:39.113797 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:39.113857 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52) 12:32:40.112605 IP 10.37.52.254.5678 > 10.2.19.1.53: 41094+ A? cloud.mikrotik.com. (36) 12:32:40.112668 IP 10.2.19.1.53 > 10.37.52.254.5678: 41094 1/0/0 A 159.148.147.229 (52)
Κάποιες προτεινόμενες λύσεις στο συγκεκριμένο πρόβλημα είναι οι ακόλουθες:
/interface detect-internet set detect-interface-list=none
/ip cloud set ddns-enabled=no
/ip cloud set update-time=no
/system clock set time-zone-autodetect=no
/ip dns set allow-remote-requests=yes
Το παρακάτω, στέλνει ΟΛΕΣ τις Internet διευθύνσεις στους Internet servers & ΟΛΕΣ τις AWMN διευθύνσεις στον wind.awmn server
/ip dns set servers=8.8.8.8,8.8.4.4,1.1.1.1 /ip dns static add forward-to=10.19.143.12 regexp=".*\\.awmn\$"
Προσθέτουμε τα ονόματα του κόμβου μας (για παράδειγμα, κόμβος soleo 10.38.128.0/24) ως εξής:
/ip dns static add name=router.soleo.awmn address=10.38.128.5
για τις wifi (BB link) συνδέσεις, ακολουθούμε το παρακάτω πρότυπο (gw-όνομα-απέναντι-κόμβου)):
/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 address σε όνομα ( name= ) ώστε να γίνεται σωστά η επίλυση της IP σε όνομα προκειμένου να ΜΗΝ δημιουργείται πρόβλημα στις περισσότερες εφαρμογές που πλέον το απαιτούν για λόγους ασφαλείας
Αν θέλουμε να δώσουμε επιπλέον ονομασίες σε μια IP, ο σωστός & προτεινόμενος τρόπος είναι ο πιο κάτω:
/ip dns static add name=alias.soleo.awmn type=CNAME cname=router.soleo.awmn
με τον παραπάνω τρόπο, όταν δίνουμε (για επίλυση σε όνομα) μια IP, για παράδειγμα: 10.38.128.5, η απάντηση θα είναι ΠΑΝΤΑ μια & μοναδική (όπως απαιτείται κατά τα πρότυπα) –> router.soleo.awmn
όλες οι επιπλέον ονομασίες ορισμένες σαν CNAME θα αντιστοιχούν στον router.soleo.awmn δηλαδή –> 10.38.128.5
η ανάπτυξη του AWMN δικτύου είναι βασισμένη σε κόμβους με πολλαπλές συνδέσεις, με αποτέλεσμα πολλές φορές να υπάρχει ασυμμετρία σε αρκετές διαδρομές μέσα σε αυτό. η χρήση stateful filtering δημιουργεί πρόβλημα στο DNS το οποίο λειτουργεί σε UDP. ο δημιουργός του tinc-vpn εξέφρασε σχετικά το παρακάτω:
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
ανατρέχοντας στις βασικές οδηγίες ρύθμισης & λειτουργίας firewall της Mikrotik έχουμε την παρακάτω υπενθύμιση:
/ip firewall filter add chain=input connection-state=invalid action=drop comment="Drop Invalid connections" add chain=input connection-state=established,related,untracked action=accept comment="Allow Established/Related/Untracked connections
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,related,untracked action=accept comment="Allow Established/Related/Untracked connections del chain=input connection-state=invalid action=drop comment="Drop Invalid connections"
το παρακάτω παράδειγμα δείχνει καθαρά το πρόβλημα:
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
happy 3D flying
η παραπάνω διαδικασία:
πατώντας σε κάθε AS κόμβο, η πλοήγηση μεταφέρεται αυτόματα στον συγκεκριμένο κόμβο για περαιτέρω εξέταση