AWS Site-to-Site VPN σε NAT Gateway: VGW ή Transit Gateway

Όλοι σχεδιάζουν το ίδιο διάγραμμα την πρώτη φορά: VPN στο VPC, NAT gateway έξω στο διαδίκτυο, τέλος. Το AWS δεν υποστηρίζει αυτή τη διαδρομή όταν το VPN τερματίζει σε virtual private gateway, και η αποτυχία είναι τόσο ήσυχη που οι ομάδες το ξαναχτίζουν περισσότερες από μία φορές. Το σχέδιο που δουλεύει απαιτεί transit gateway, που αλλάζει το gateway και τους πίνακες δρομολόγησης και στις δύο πλευρές. Συγκρίνετε τις δύο μορφές πριν σχεδιάσετε.

Η τοπολογία που φαίνεται προφανής και δεν υποστηρίζεται

Η τεκμηρίωση του NAT gateway στο AWS τραβά μια γραμμή που εκπλήσσει όποιον έχει φτιάξει μόνο σχέδια ενός VPC: η κίνηση από σύνδεση Site-to-Site VPN δεν δρομολογείται σε NAT gateway μέσω virtual private gateway. Ο τύπος gateway όπου τερματίζει το VPN καθορίζει αν υπάρχει καθόλου διαδρομή μετάφρασης. Το λάθος επιβιώνει γιατί η κατάσταση της σήραγγας είναι UP και ένα instance EC2 στο ίδιο subnet φτάνει στο διαδίκτυο χωρίς πρόβλημα. Καμία από τις δύο παρατηρήσεις δεν ελέγχει τη σπασμένη κατεύθυνση.

Στην πράξη το πακέτο φτάνει με διεύθυνση πηγής από το τοπικό δίκτυο και δεν βρίσκει υποστηριζόμενο επόμενο hop που θα το μεταφράσει. Ανάλογα με τους πίνακες απορρίπτεται στο όριο εξόδου, και επειδή η σήραγγα μένει UP ενώ ένα instance φτάνει στο διαδίκτυο, η αποτυχία αναφέρεται ως πρόβλημα firewall στο τοπικό δίκτυο.

Virtual private gateway ή transit gateway

Ένα virtual private gateway ανήκει σε ένα VPC. Τερματίζει το VPN, εγκαθιστά routes στους πίνακες αυτού του VPC και σταματά εκεί. Δεν έχει μοντέλο attachment, οπότε δεν μπορεί να δώσει κίνηση σε άλλο VPC ή σε κοινό τμήμα εξόδου. Αυτό το εύρος ενός VPC είναι ολόκληρος ο περιορισμός και κανένα route μέσα στο VPC δεν το αλλάζει.

Το transit gateway είναι περιφερειακός κόμβος όπου το VPN, κάθε spoke VPC και ένα VPC κοινών υπηρεσιών εμφανίζονται ως attachments. Έχει δικούς του πίνακες δρομολόγησης που επιλέγουν ποιο attachment λαμβάνει ένα prefix.

Αυτός ο κόμβος κάνει δυνατή την κεντρική έξοδο: το VPN προσγειώνεται ως ένα attachment, το VPC εξόδου ως άλλο, και ένας πίνακας του transit gateway στέλνει τα prefixes προς το διαδίκτυο από το πρώτο στο δεύτερο. Με virtual private gateway δεν υπάρχει δεύτερο attachment, γι' αυτό το σχέδιο δεν μπαλώνεται εκ των υστέρων.

Η υποστηριζόμενη διαδρομή εξόδου, βήμα βήμα

Το σχέδιο αναφοράς έχει πέντε hops και κάθε βέλος είναι απόφαση δρομολόγησης που πρέπει να ρυθμίσετε. Η κίνηση φεύγει από το τοπικό δίκτυο στο attachment Site-to-Site VPN, ο πίνακας του transit gateway τη στέλνει στο attachment του VPC εξόδου, όπου ο πίνακας του subnet τη στέλνει σε δημόσιο NAT gateway. Το NAT gateway μεταφράζει την πηγή και το internet gateway βγάζει το πακέτο έξω.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Δύο λεπτομέρειες κρίνουν τα τελευταία hops. Το NAT gateway πρέπει να είναι δημόσιο, με elastic IP και route προς internet gateway, γιατί ένα ιδιωτικό NAT gateway μεταφράζει μεταξύ δικτύων και δεν γίνεται ποτέ έξοδος στο διαδίκτυο.

Σχεδιάστε ένα NAT gateway ανά Availability Zone που θέλετε να εξυπηρετήσετε, με κάθε πίνακα subnet να δείχνει στο τοπικό. Κρατήστε τον πίνακα του transit gateway και τους πίνακες του VPC ως ξεχωριστά αντικείμενα στις σημειώσεις σας, γιατί ο ένας επιλέγει attachment και ο άλλος πόρο μέσα στο VPC. Ένα default route μόνο στον έναν αφήνει τη μισή διαδρομή ακαθόριστη και παράγει τις μερικές αστοχίες που είναι πιο δύσκολο να αποδοθούν.

Η διαδρομή επιστροφής είναι όπου αποτυγχάνουν αυτά τα σχέδια

Το NAT gateway κρατά κατάσταση για ροές που έχει δει, οπότε οι απαντήσεις σε εξερχόμενη σύνδεση επιστρέφουν χωρίς νέο κανόνα εισόδου. Αυτή η ιδιότητα δεν δημοσιεύει τοπική υπηρεσία στο διαδίκτυο, και το να τη μεταχειρίζεστε σαν να το κάνει κοστίζει σε μια ομάδα μια μέρα debugging μιας σύνδεσης που δεν θα γινόταν ποτέ. Για κίνηση από τον πελάτη πρέπει να συμφωνήσουν τέσσερα routes: η τοπική πολιτική, ο πίνακας του transit gateway, ο πίνακας του subnet εξόδου και ο πίνακας του subnet NAT. Αν λείπει ο τελευταίος, το αίτημα φεύγει από το κτίριο ενώ η απάντηση πεθαίνει μέσα στο AWS.

Επαληθεύστε με πραγματικό πελάτη πίσω από το VPN και δείτε ποια δημόσια διεύθυνση πηγής παρουσιάζει. Αν είναι η elastic IP του NAT gateway, γίνεται μετάφραση· αν είναι κάτι άλλο, μετράτε άλλη έξοδο.

Η ασύμμετρη εκδοχή αυτής της αποτυχίας αξίζει να αναγνωρίζεται νωρίς. Όταν ο πίνακας NAT subnet μιας Availability Zone έχει το route επιστροφής στο prefix του πελάτη και άλλος όχι, οι νέες συνδέσεις πετυχαίνουν ή αποτυγχάνουν ανάλογα με τη ζώνη όπου πέφτει η ροή, και το μοτίβο διαβάζεται λάθος ως ασταθές διαδίκτυο. Συγκρίνετε τους πίνακες subnet για κάθε ζώνη που εξυπηρετείτε αντί να διορθώσετε αυτή όπου άνοιξε το ticket, γιατί το route που λείπει είναι ολόκληρη η βλάβη και στην άλλη πλευρά δεν χρειάζεται αλλαγή.

Πότε ένα ρητό proxy είναι το καλύτερο σχέδιο

Ένα HTTP proxy σε instance στο VPC εξόδου είναι νόμιμη εναλλακτική και συχνά φθηνότερη. Οι πελάτες ρυθμίζονται να το χρησιμοποιούν, το proxy ανοίγει τη δική του σύνδεση προς τα έξω και η διαδρομή επιστροφής γίνεται δικό του πρόβλημα αντί για παζλ συμμετρικής δρομολόγησης. Για λίγες εφαρμογές αφαιρεί το μεγαλύτερο μέρος της δουλειάς του transit gateway. Δίνει επίσης logging ανά χρήστη που ένα NAT gateway δεν μπορεί να παράγει.

Δεν είναι όμως διαφανές. Ό,τι αγνοεί τις ρυθμίσεις proxy και κάθε πρωτόκολλο που δεν είναι HTTP δεν θα ακολουθήσει αυτή τη διαδρομή.

Η επιλογή εξαρτάται από το τι μιλούν πραγματικά οι εφαρμογές σας και πόση ταυτότητα χρειάζεστε στα logs. Όπου μιλούν HTTP, το proxy κερδίζει τη θέση του· όπου χρειάζεστε γενική έξοδο για αυθαίρετα πρωτόκολλα, το σχέδιο με transit gateway είναι αυτό που υποστηρίζει το AWS. Το να το αποφασίσετε εκ των προτέρων είναι φθηνότερο από το να το ανακαλύψετε αφού χτιστούν οι πίνακες.