Τρία φίλτρα που σταματούν ένα customer BGP gateway να διαρρέει routes

Ένα αποκλειστικό gateway ανά πελάτη, που χτίζουμε και λειτουργούμε εμείς, με εσωτερικό peering προς το policy gateway μας πάνω από ιδιωτικούς αριθμούς AS, είναι ο σωστός σχεδιασμός: απομόνωση, μια πολιτική που ανήκει σε αυτούς, και routing που προσαρμόζεται μόνο του. Το BGP είναι εσωτερικό στην πλατφόρμα μας, όχι μια συνεδρία που τρέχει ο πελάτης. Σημαίνει όμως ότι τώρα λειτουργείτε πολλούς μικρούς BGP speakers, και μία απρόσεκτη ρύθμιση σε οποιονδήποτε από αυτούς μπορεί να ανακοινώσει routes που δεν θα έπρεπε ποτέ να ανακοινώσει. Αυτό το άρθρο καλύπτει πώς συμβαίνει αυτό και τις τρεις δικλείδες που βάζουμε σε κάθε customer gateway ώστε να μην μπορεί.

Γιατί τα gateways ανά πελάτη μιλούν BGP

Ένας κοινόχρηστος VPN concentrator με static routes μοιάζει απλούστερος, μέχρι να χρειαστεί να προσθέσετε ένα subnet, να μετακινήσετε έναν πελάτη ανάμεσα σε firewalls, ή να επιβιώσετε μια βλάβη gateway. Με ένα αποκλειστικό gateway ανά πελάτη, που το καθένα τρέχει ένα ιδιωτικό AS μέσα στην πλατφόρμα μας και κάνει peering με ένα κεντρικό policy gateway, η προσθήκη ενός δικτύου είναι μια ανακοίνωση, και η απώλεια μιας διαδρομής είναι μια απόσυρση που συγκλίνει μόνη της. Η πολιτική του πελάτη μένει στο edge του πελάτη, και η πολιτική transit μένει κεντρική.

Το τίμημα είναι ότι κάθε gateway μπορεί πλέον να επηρεάσει το routing για όλους. Χρειάζεται λοιπόν δικλείδες που δεν εξαρτώνται από το να είναι κάποιος προσεκτικός.

Πώς συμβαίνουν στ' αλήθεια οι διαρροές

Στα περισσότερα δημοσιευμένα post-mortems, η αιτία μιας διαρροής routes από μια συσκευή edge σπάνια είναι κάποιο εξωτικό σφάλμα του BGP. Είναι το redistribution. Κάποιος ενεργοποιεί «redistribute connected» ή «redistribute static» για να γλιτώσει πληκτρολόγηση, και το gateway αρχίζει να ανακοινώνει το δικό του WAN link, το pool του VPN tunnel του, ένα subnet διαχείρισης, ή ένα route που έμαθε από κάπου αλλού. Σε ένα open source firewall με routing daemon, αυτή η επιλογή συχνά απέχει ένα checkbox.

Μόλις ένα διαρρεύσαν route γίνει αποδεκτό upstream, η κίνηση για εκείνο το prefix μπορεί να τραβηχτεί προς το λάθος gateway, ή το δίκτυο ενός πελάτη μπορεί να γίνει προσβάσιμο από σημεία που δεν θα έπρεπε. Τίποτα δεν κρασάρει. Η κίνηση απλώς πηγαίνει κάπου απροσδόκητα.

Δικλείδα πρώτη: ανακοίνωση με ρητά network statements

Ένα gateway πρέπει να ανακοινώνει ακριβώς τα prefixes που ανήκουν στον πελάτη, ένα προς ένα, και τίποτα άλλο. Σε FRR, που βρίσκεται κάτω από πολλά routing plugins των firewalls, αυτό μοιάζει έτσι:

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

Το network statement ανακοινώνει μόνο ένα prefix που υπάρχει πραγματικά στον πίνακα δρομολόγησης, οπότε ένα τυπογραφικό λάθος δεν ανακοινώνει τίποτα αντί για κάτι λάθος.

Δικλείδα δεύτερη: ένα outbound prefix list που ταιριάζει

Ζώνη και τιράντες. Ακόμα και με ρητά network statements, ένα outbound prefix list επιτρέπει μόνο τα prefixes του ίδιου του πελάτη και απορρίπτει όλα τα υπόλοιπα:

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

Αν κάτι προσπαθήσει ποτέ να ανακοινώσει περισσότερα, αυτή η λίστα το ρίχνει στην έξοδο. Καθρεφτίστε τη και στην πλευρά που λαμβάνει: το κεντρικό gateway δέχεται από κάθε πελάτη μόνο τα prefixes που έχουν ανατεθεί σε εκείνον τον πελάτη.

Δικλείδα τρίτη: κανένα redistribution, και έλεγχος ότι μένει κλειστό

Το redistribution είναι απενεργοποιημένο, και είναι μέρος της διαμόρφωσης που επαληθεύετε, όχι υπόθεση. Σε FRR μπορείτε να ελέγξετε με μία γραμμή:

vtysh -c 'show running-config' | grep -i redistribute

Ένα κενό αποτέλεσμα είναι το μόνο αποδεκτό αποτέλεσμα. Επειδή ορισμένες διεπαφές firewall εκθέτουν το redistribution ως ένα βολικό checkbox, αυτός ο έλεγχος ανήκει στην επαλήθευση της κατασκευής σας, όχι μόνο στον αρχικό σχεδιασμό.

Σύγκριση με ένα γνωστό καλό gateway πριν την παράδοση

Τρεις δικλείδες αποτρέπουν τις διαρροές. Δεν αποτρέπουν την άλλη συνηθισμένη αποτυχία των gateways ανά πελάτη: μία ρύθμιση που διαφέρει από τα gateways που δουλεύουν, προκαλώντας ένα VPN που «δεν συνδέεται» ή συνδέεται χωρίς να φτάνει πουθενά. Ένας κανόνας pass που λείπει για τη θύρα του VPN στη διεπαφή WAN, ένα outbound NAT που έμεινε σε αυτόματη λειτουργία, ένας κανόνας διεπαφής πιο περιοριστικός από ό,τι προβλεπόταν, μια ελαφρώς διαφορετική επιλογή authentication: το καθένα ξεφεύγει εύκολα με το μάτι.

Η θεραπεία είναι μηχανική. Ρυθμίστε κάθε gateway μέσω του API του, ποτέ με το χέρι, μετά τραβήξτε τις ίδιες ρυθμίσεις από ένα δοκιμασμένο gateway αναφοράς και από το νέο και συγκρίνετέ τες πεδίο προς πεδίο:

• Ρυθμίσεις του VPN instance: πρωτόκολλο, θύρα, ciphers, λειτουργία authentication, pushed routes και DNS.
• Κανόνες firewall στο WAN για τη θύρα του VPN και τα διαγνωστικά.
• Κανόνες στην ίδια τη διεπαφή του VPN.
• Λειτουργία και κανόνες outbound NAT.
• Διαμόρφωση BGP, μαζί με το πεδίο redistribution.

Κάθε διαφορά που δεν είναι ρητά αναμενόμενη για αυτόν τον πελάτη μπλοκάρει την παράδοση. Κανένα διαπιστευτήριο δεν φεύγει από το κτίριο μέχρι η σύγκριση να είναι καθαρή. Παίρνει δευτερόλεπτα και αντικαθιστά ένα απόγευμα απομακρυσμένης αντιμετώπισης προβλημάτων με έναν χρήστη που απλώς θέλει να δουλέψει.

Πρόσβαση ανά άτομο, σωστά

Ένα client certificate ανά άτομο, υπογεγραμμένο από μια αρχή πιστοποίησης που ανήκει στον πελάτη, συν ένα διαπιστευτήριο, σημαίνει ότι ένα χαμένο laptop είναι ένα ανακληθέν πιστοποιητικό και κανείς άλλος δεν επηρεάζεται. Μια σταθερή διεύθυνση tunnel ανά άτομο επιτρέπει στην πολιτική του firewall να ακολουθεί ένα πρόσωπο από συσκευή σε συσκευή.

Λίστα ελέγχου για τα δικά σας gateways

• Ανακοινώνεται κάθε prefix πελάτη με ρητό network statement;
• Υπάρχει outbound prefix list σε κάθε συνεδρία πελάτη, και αντίστοιχο inbound κεντρικά;
• Επιστρέφει κενό ένα grep για redistribute σε κάθε gateway;
• Ρυθμίζονται τα gateways μέσω API, με το αποτέλεσμα να συγκρίνεται με μια γνωστή καλή αναφορά πριν την παράδοση;
• Είναι η απομακρυσμένη πρόσβαση ανά άτομο, με πιστοποιητικά που μπορείτε να ανακαλέσετε μεμονωμένα;

Κάθε customer gateway που χτίζουμε έχει αυτές τις δικλείδες, στο δικό του segment και στο δικό του firewall. Αν θέλετε ιδιωτική πρόσβαση στην πλατφόρμα σας χτισμένη έτσι, ευχαρίστως να βοηθήσουμε.

Μιλήστε με έναν μηχανικό

Σχετικά: Ιδιωτική διασύνδεση: VPN gateways και μισθωμένες γραμμές · Managed περιμετρικά firewalls · Κρυπτογραφημένο backbone πολλών sites: το DMVPN mesh