Połączenie Sophos Firewall z AWS Site-to-Site VPN

AWS Site-to-Site VPN łączy lokalną sieć za Sophos Firewall z AWS VPC albo Transit Gateway. Technicznie jest to VPN IPsec, ale operacyjnie różni się od zwykłego tunelu Sophos-to-Sophos: AWS tworzy dwa tunele dla jednego połączenia VPN, używa obiektów Customer Gateway i bramy docelowej, a routing mocno zależy od wyboru tras statycznych albo BGP.

Ten artykuł opisuje praktyczną konfigurację Sophos Firewall z AWS. Uzupełnia ogólną instrukcję Konfiguracja Sophos Firewall Site-to-Site IPsec VPN o elementy specyficzne dla AWS: dwa tunele, sąsiadów BGP, route tables, security groups, NACLs oraz kontrolę statusu w AWS i Sophos. Jeżeli tunel jest już zestawiony, ale ruch nie przechodzi, lepszym kolejnym krokiem jest Troubleshooting Sophos Firewall IPsec VPN.

Kiedy ten artykuł pasuje

Artykuł pasuje, gdy oddział, centrum danych albo lokalna sieć ma zostać połączona z AWS przez Sophos Firewall. Obejmuje AWS Site-to-Site VPN do VPC, Virtual Private Gateway albo Transit Gateway. Nie opisuje Sophos Firewall jako appliance wirtualnego uruchomionego bezpośrednio w AWS.

Typowe scenariusze:

• lokalna sieć serwerowa do instancji EC2 w VPC
• ruch backupu, monitoringu albo zarządzania do AWS
• hybrydowy DNS, AD, jump hosty albo sieci administracyjne
• migracja ze statycznego VPN do dynamicznego routingu BGP
• redundantna praca z dwoma tunelami AWS

AWS i Sophos używają różnych pojęć. W AWS pracuje się z Customer Gateway, Virtual Private Gateway albo Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups i Network ACLs. Na Sophos Firewall istotne są połączenia Amazon VPC, profile IPsec, interfejsy XFRM, BGP, trasy i reguły firewall.

Planowanie przed konfiguracją

AWS Site-to-Site VPN nie powinno być traktowane jako samo zaimportowanie pobranego przykładowego pliku. Plik AWS jest pomocny, ale produkcyjna akceptacja zależy od routingu, security groups, NACLs, reguł firewall oraz testów z rzeczywistym ruchem.

Ustalić sieci i bramę docelową

Najpierw trzeba zdecydować, która strona AWS będzie używana:

• Virtual Private Gateway dla klasycznej pojedynczej VPC.
• Transit Gateway dla wielu VPC, wielu lokalizacji albo większego projektu routingu.
• Cloud WAN albo inne warianty tylko wtedy, gdy architektura AWS świadomie tego wymaga.

Wcześniej udokumentować:

• AWS VPC CIDR, na przykład 10.60.0.0/16
• istotne AWS subnets i route tables
• lokalne sieci za Sophos Firewall, na przykład 172.16.20.0/24
• publiczny adres IP Sophos Firewall albo routera upstream
• tryb routingu: static albo dynamic BGP
• lokalny i AWS ASN, jeżeli używany jest BGP
• oczekiwane cele testowe po obu stronach
• planowane tunnel options, wersję IKE, preshared keys i lifetimes

Nakładające się sieci należy uporządkować przed projektem VPN. NAT over IPsec może działać, ale utrudnia route tables, security groups, logi i późniejsze troubleshooting.

Traktować oba tunele poważnie

AWS tworzy dwa tunele dla każdej Site-to-Site VPN connection, każdy z innym endpointem AWS. Oba tunele powinny być skonfigurowane i sprawdzone na Sophos Firewall. Jeden tunel jest wygodny w laboratorium, ale w produkcji rezygnuje się wtedy z redundancji AWS.

Ważne jest właściwe oczekiwanie: ścieżka zwrotna z AWS preferuje jeden tunel zależnie od routingu i strony AWS, a w razie awarii może przełączyć się na drugi. Nie oznacza to, że oba tunele zawsze są wykorzystywane równomiernie. Liczy się to, aby oba tunele się zestawiały, BGP albo trasy statyczne były poprawne, a failover został przetestowany.

Routing statyczny albo BGP

AWS Site-to-Site VPN obsługuje trasy statyczne i dynamiczny routing z BGP. BGP jest zwykle lepszy przy wielu prefiksach, przyszłej rozbudowie albo Transit Gateway. Trasy statyczne są prostsze, ale każda zmiana sieci wymaga ręcznej aktualizacji.

W praktyce:

• BGP wymaga zgodnych wartości ASN po obu stronach.
• Sophos Firewall musi ogłaszać właściwe lokalne prefiksy.
• AWS route tables muszą faktycznie używać tras propagowanych albo statycznych.
• Security groups i NACLs również muszą zezwalać na ruch.
• Identyczne trasy statyczne i BGP mogą powodować nieoczekiwane priorytety.

Przygotowanie AWS

Poniższe kroki opisują typowy przebieg. Szczegóły różnią się między Virtual Private Gateway i Transit Gateway, ale zasada pozostaje taka sama.

Utworzyć Customer Gateway

Customer Gateway opisuje lokalną stronę Sophos w AWS.

Wprowadzić:

1. W konsoli AWS przejść do VPC > Virtual private network (VPN) > Customer gateways i wybrać Create customer gateway.
2. Ustawić Name tag, na przykład cgw-sophos-hq.
3. Jeśli planowane jest użycie BGP, ustawić BGP ASN dokładnie na lokalny ASN Sophos. AWS pokazuje to pole także dla połączeń z routingiem statycznym, ale routing statyczny nie zestawia peeringu BGP.
4. W IP address wprowadzić statyczny, osiągalny z Internetu adres strony Sophos. Jeśli firewall znajduje się za urządzeniem NAT działającym przed nim, dla AWS Customer Gateway podać publiczny adres IP tego urządzenia NAT, a nie adres interfejsu WAN Sophos.
5. Opcjonalnie wpisać czytelną nazwę w Device, a następnie wybrać Create customer gateway.

Jeżeli Sophos Firewall znajduje się za routerem albo urządzeniem operatora, musi być jasne, jaki publiczny IP widzi AWS i czy NAT-T działa poprawnie. Zgodnie z opcjami AWS Customer Gateway między siecią lokalną a endpointami AWS Site-to-Site VPN musi być dozwolony UDP 500 oraz, przy użyciu NAT-T, UDP 4500. Urządzenie NAT/firewall działające przed Sophos należy skonfigurować tak, aby zezwalało na te porty i przekazywało je między interfejsem WAN Sophos a adresami obu endpointów tuneli AWS z pliku konfiguracyjnego; zobacz bezpośrednie reguły firewalla AWS.

Utworzyć albo wybrać bramę docelową

Dla jednej VPC zwykle tworzy się Virtual Private Gateway w VPC > Virtual private network (VPN) > Virtual private gateways i dołącza przez Actions > Attach to VPC. Większe środowiska AWS często używają Transit Gateway.

Sprawdzić:

• Brama jest dołączona do właściwej VPC albo Transit Gateway.
• ASN po stronie AWS nie koliduje z ASN Sophos.
• Route tables VPC albo Transit Gateway są zaplanowane.
• Subnety używane do testów korzystają z właściwej route table.

Utworzyć Site-to-Site VPN connection

Następnie przejść do VPC > Virtual private network (VPN) > Site-to-Site VPN connections i wybrać Create VPN connection. Aktualna procedura AWS opisuje te same zasoby i wartości zależne od projektu.

Ważne punkty:

• W Target gateway type wybrać zaplanowany Virtual Private Gateway albo Transit Gateway.
• W Customer gateway wybrać Existing i wcześniej utworzony Customer Gateway.
• Ustawić Routing options na Dynamic (requires BGP) albo Static; w Static IP prefixes wprowadzić tylko lokalne prefiksy, które AWS ma osiągać przez VPN.
• Świadomie sprawdzić Tunnel Options, szczególnie IKE version, encryption, integrity, DH/PFS i DPD.
• Udokumentować preshared keys dla każdego tunelu albo świadomie pozwolić AWS je wygenerować.

W przypadku routingu dynamicznego Sophos wymaga ustawienia Local IPv4 Network Cidr i Remote IPv4 Network Cidr w połączeniu AWS na 0.0.0.0/0, aby możliwe było zestawienie peeringu BGP. Jeżeli na firewallu skonfigurowano już Local AS, dokładnie ten ASN należy podać dla AWS Customer Gateway.

Po utworzeniu wybrać Download configuration. Dla automatycznego importu Sophos wybrać Vendor Sophos, Platform Sophos Firewall, Software v19+ oraz faktycznie planowaną IKE version. Plik jest tylko przykładową konfiguracją: algorytmy, grupy DH, certyfikaty i rodzina adresów IP muszą odpowiadać projektowi produkcyjnemu. Za NAT przed importem w obu blokach tunnel_outside_address po stronie customer gateway wprowadzić lokalny adres interfejsu WAN Sophos. Pozostawić zewnętrzne endpointy po stronie AWS bez zmian; nie zastępować zbiorczo każdego bloku XML o tej samej nazwie. W AWS Customer Gateway pozostaje natomiast publiczny adres urządzenia NAT działającego przed firewallem. Dla tras statycznych wybrać Generic i skonfigurować ręcznie. Dynamiczny BGP również można skonfigurować ręcznie przy użyciu opisanego poniżej pobrania Generic; import Sophos nie jest jedyną ścieżką konfiguracji BGP.

Sprawdzić route tables, security groups i NACLs

Zielony tunel VPN w AWS nie oznacza jeszcze, że instancja EC2 jest osiągalna.

Do walidacji sprawdzić:

• VPC route table zawiera trasę do lokalnej sieci przez Virtual Private Gateway albo Transit Gateway.
• Przy Virtual Private Gateway route propagation jest włączone albo trasa jest ustawiona statycznie.
• Transit Gateway route tables zawierają właściwe attachments i propagations.
• Security group instancji docelowej zezwala na wymagany ruch z lokalnej sieci.
• Network ACLs zezwalają na ruch w obie strony.
• Firewall systemu operacyjnego instancji nie blokuje testu.

Ten etap jest często pomijany, ponieważ Sophos i AWS mogą pokazywać połączony tunel, mimo że instancja nie odpowiada z powodu security group albo trasy zwrotnej.

Konfiguracja Sophos Firewall

Sophos oferuje dla AWS dwie praktyczne ścieżki: import przez Site-to-site VPN > Amazon VPC albo ręczną konfigurację jako route-based IPsec. W wielu wdrożeniach AWS import jest najczystszym początkiem, ale automatycznie utworzone obiekty nadal trzeba sprawdzić.

Zaimportować konfigurację AWS

W sekcji Site-to-site VPN > Amazon VPC Sophos Firewall może zaimportować połączenie przez Use AWS security credentials albo Use VPC configuration file. Dla metody z poświadczeniami należy użyć dedykowanego użytkownika AWS IAM z uprawnieniami wymaganymi do ustawień Site-to-Site VPN; access key i secret key trzeba chronić i rotować tak jak inne sekrety administracyjne.

Import jest migawką. Po zmianie opcji tunelu lub innych wartości połączenia w AWS należy ponownie zaimportować ustawienia, a następnie powtórzyć pełną walidację. Wcześniejszy import nie śledzi automatycznie konfiguracji AWS.

Poniższa procedura używa pobranego pliku konfiguracyjnego AWS:

Kroki:

1. Otworzyć Sophos Firewall.
2. Przejść do Site-to-site VPN > Amazon VPC.
3. Wybrać Use VPC configuration file.
4. Wgrać plik konfiguracyjny AWS.
5. Uruchomić import.
6. Sprawdzić utworzone połączenia, profile IPsec, interfejsy XFRM i ustawienia BGP.

Import tworzy profile IPsec, ustawienia BGP i interfejsy XFRM. Następnie w Routing > BGP > Networks należy dodać lokalne prefiksy. W Administration > Device access opcja IPsec musi być włączona dla WAN, a Dynamic Routing dla VPN. Ustawienia te zezwalają na ruch sterujący tunelem i routingiem; nie zastępują reguły firewalla dla ruchu użytkowego.

Za NAT w każdej z dwóch sekcji tuneli sprawdzić, czy tunnel_outside_address po stronie customer gateway zawiera lokalny adres WAN Sophos. Nie zmieniać zewnętrznych adresów po stronie AWS; publiczny adres NAT pozostaje adresem AWS Customer Gateway. Jeżeli przypisanie jest niejasne, nie aktywować pliku ani zaimportowanych obiektów, lecz najpierw jednoznacznie zidentyfikować stronę klienta i stronę AWS.

Ręcznie skonfigurować dwa tunele IPv4 do VGW z BGP

Ten wariant opisuje połączenie IPv4 z Virtual Private Gateway dołączoną do VPC, z opcją Dynamic (requires BGP). Nie jest to runbook dla IPv6, Transit Gateway ani Cloud WAN i nie stanowi ogólnego stwierdzenia, że AWS nie obsługuje IPv6. Warunkami wstępnymi są uprawnienia AWS, lokalne uprawnienia administracyjne, osiągalne zewnętrzne endpointy, nienakładające się sieci i zatwierdzona ścieżka powrotna. Nie aktywować jednocześnie importu i równoległej konfiguracji ręcznej dla tych samych tras.

1. W AWS dla przewidzianego połączenia VPN otworzyć Download configuration: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Dotyczy to wyraźnie także ręcznej konfiguracji dynamicznego BGP. Plik zawiera PSK: przechowywać go w postaci zaszyfrowanej i z ograniczonym dostępem.
2. Dla każdego tunelu osobno zapisać zewnętrzny endpoint, PSK, wewnętrzny CIDR, wewnętrzny adres strony klienta, wewnętrzny adres AWS i ASN z faktycznie wygenerowanej konfiguracji. Użyć dwóch różnych sieci /30 akceptowanych przez AWS z zakresu 169.254.0.0/16; nie używać zakresów zarezerwowanych ani już wykorzystywanych. Poniższe przypisanie jest czytelnym przykładem planistycznym, a nie przydziałem dokonanym przez AWS:

Tabela przypisania: zewnętrzny IP służy do zestawienia IPsec; wewnętrzny IP adresuje XFRM i BGP. Używać wyłącznie adresów faktycznie przydzielonych przez AWS: nie wyciągać wniosków o własnym przydziale z kolejności przykładowych adresów. Adres SFOS XFRM jest wewnętrznym adresem strony klienta, nigdy wewnętrznym adresem AWS ani publicznym IP. Sąsiadem BGP jest wewnętrzny adres AWS, a nie zewnętrzny endpoint.

3. W Profiles > IPsec profiles > Add utworzyć profil niestandardowy o jednoznacznej nazwie. Przykładem o ograniczonym zakresie, dla tuneli skonfigurowanych w ten sposób po obu stronach, jest IKEv2, faza 1 AES256 / SHA2 256 / DH 14 (DH2048) i faza 2 AES256 / SHA2 256 / PFS 14 (DH2048). Włączyć Re-key connection; Key negotiation tries 0 i wyłączone Use strict profile stosować tylko wtedy, gdy przewiduje to zatwierdzony plan eksploatacji. Wybrane algorytmy i grupy DH/PFS muszą tworzyć wspólny, dozwolony zestaw parametrów negocjacji, a nie tylko mieć tę samą nazwę profilu.
4. Osobno udokumentować czasy ważności oraz Rekey/DPD. Historyczny przykład podaje dla AWS fazę 1 28800 sekund, ale dla SFOS Key life 28000; fazę 2 po obu stronach 3600, Rekey Margin 360 i Fuzz 50 procent. Różne lokalne timery rekey IKEv2 nie oznaczają automatycznie błędu parametrów negocjacji ani nie są dowodem przetestowanej interoperacyjności. Nie przyjmować po cichu sprzecznego timera jako uniwersalnego standardu: użyć faktycznie skonfigurowanych wartości AWS i zatwierdzonego dla nich planu rekey SFOS; przy niejasnych warunkach zatrzymać zmianę i wyjaśnić. Przykład DPD to AWS Restart oraz włączone DPD w SFOS, interwał sprawdzania 30, czas oczekiwania na odpowiedź 120 sekund i Re-initiate. Te wartości są przykładem profilu wymagającym sprawdzenia, a nie uniwersalnym zaleceniem. Przed eksploatacją produkcyjną potwierdzić zachowanie Rekey/DPD we własnym oknie zmian.
5. W Site-to-site VPN > IPsec > Add utworzyć dla każdego tunelu osobne połączenie z Connection type Route-based (Tunnel interface), IP version IPv4 i Gateway type Initiate the connection. W Profile wybrać właśnie sprawdzony profil niestandardowy, a nie bez sprawdzenia inny profil domyślny o nazwie IKEv2. Ustawić Authentication type Preshared key i dokładnie PSK tego tunelu. Listening interface to lokalny interfejs WAN; Gateway address to odpowiedni zewnętrzny endpoint AWS. Lokalne i zdalne identyfikatory IKE ustawiać wyłącznie zgodnie z rzeczywiście oczekiwanym planem tożsamości, nigdy nie używać przypadkowych IP; za NAT lokalny adres WAN nie jest tożsamy z publicznym adresem Customer Gateway. Activate on save wybrać dopiero po sprawdzeniu, w zatwierdzonym oknie; zapisać i aktywować oba połączenia.
6. W Network > Interfaces otworzyć XFRM należący do danego połączenia i sprawdzić powiązanie z połączeniem. W IPv4/netmask wprowadzić wewnętrzny IP strony klienta oraz /30 (255.255.255.252) tego tunelu. Dla drugiego XFRM użyć jego własnego wewnętrznego IP; nie zamieniać przypisań.
7. W Routing > BGP > Global configuration zachować już używany Local AS albo ustawić zatwierdzony ASN Customer Gateway. Użyć jednoznacznej, stabilnej Router ID z własnego planu. Nie nadpisywać istniejącego globalnego ASN na potrzeby tego VPN; AWS musi używać tej samej lokalnej wartości ASN. Nie kopiować bez sprawdzenia zakresu ASN ani przykładowego ASN: najpierw sprawdzić dostępność, dopuszczalność w AWS i brak konfliktów. W Neighbors utworzyć dla każdego wewnętrznego IP AWS sąsiada IPv4 z Remote AS równym rzeczywistemu ASN VGW.
8. W Routing > BGP > Networks ogłaszać tylko zatwierdzone, lokalnie osiągalne prefiksy. W Administration > Device access zezwolić na IPsec dla WAN i Dynamic Routing dla VPN; nie dodawać ogólnego zezwolenia dla LAN, jeżeli nie przewidziano tam lokalnego sąsiada routingu. Otwarcie BGP TCP 179 jako ruchu użytkowego dla całego świata lub między wszystkimi sieciami LAN/VPN nie zastępuje tego zezwolenia dla płaszczyzny sterowania. Dodatkowo utworzyć ściśle ograniczone reguły ruchu danych opisane w następnej sekcji.
9. Dla każdego sąsiada w Routing > Information > BGP > Neighbors sprawdzić Established oraz oczekiwane prefiksy nauczone i ogłaszane. W AWS, w Tunnel Details, sprawdzić oba tunele UP i trasy BGP; skontrolować propagację tras VGW w odpowiednich tablicach routingu subnetów. Dopiero potem przetestować dozwolony ruch aplikacyjny i niedozwolone źródło. W uzgodnionym oknie wyłączyć jeden tunel w kontrolowany sposób, sprawdzić zachowanie oczekiwanej trasy i działania aplikacji przez drugi tunel, ponownie go włączyć i sprawdzić oba sąsiedztwa; bez rzeczywistego testu failover nie deklarować odbioru redundancji.

Przy błędach IPsec najpierw sprawdzić dla każdego tunelu endpoint, PSK, parametry negocjacji, identyfikatory i NAT-T; przy BGP Active najpierw sprawdzić wewnętrzne adresy XFRM, ASN, aktywację sąsiada i Device Access. Tymczasowa trasa statyczna z pingiem nie jest ogólną metodą naprawy BGP i może ukrywać nieprawidłową ścieżkę. Jeżeli znikną istniejące trasy lub przypisanie czasów ważności/identyfikatorów jest niejasne, nie próbować kolejnych wartości, lecz zatrzymać nową konfigurację i porównać ją z zabezpieczonym stanem. Ta instrukcja ma zakres ograniczony dokumentacją i nie została tu przetestowana na urządzeniu.

Sprawdzić profil IPsec i tunele

Po imporcie albo przy konfiguracji ręcznej nie należy ślepo ufać samemu statusowi.

Sprawdzić:

• Istnieją oba tunele AWS.
• Wersja IKE pasuje do konfiguracji AWS.
• Encryption, Authentication, DH Group i PFS tworzą dla każdego tunelu zestaw parametrów negocjacji (proposal) dopuszczony po obu stronach; Lifetimes i lokalne timery Rekey są sprawdzane oddzielnie pod kątem zgodności z zatwierdzonym planem, a nie wyłącznie pod kątem równości wartości liczbowych.
• Preshared key jest poprawny dla każdego tunelu.
• Gateway type i remote gateway wskazują odpowiednie endpointy tuneli AWS.
• Interfejsy XFRM istnieją i mają czytelne nazwy.

Po zmianie opcji tuneli AWS zestawy parametrów negocjacji (proposals) po stronie Sophos muszą pozostać kompatybilne, a oddzielnie udokumentowane timery Rekey/DPD muszą być zgodne z zatwierdzonym planem eksploatacji. Jednostronne zmiany algorytmu, DH/PFS, PSK lub tożsamości mogą uniemożliwić zestawienie Phase 1 lub Phase 2; same różnice w lokalnych wartościach IKEv2 Lifetimes nie dowodzą takiego błędu parametrów negocjacji.

Skonfigurować BGP albo trasy statyczne

Przy BGP w Routing > BGP sprawdza się lokalny ASN, neighbor, remote ASN i ogłaszane sieci. Pełną konfigurację i odbiór wyjaśnia artykuł Konfiguracja BGP na Sophos Firewall. W Routing > Information > BGP Neighbors, Summary i Routes powinny pokazywać oczekiwane wartości.

Przy routingu statycznym trasy do sieci AWS muszą wskazywać właściwy interfejs XFRM. AWS również musi znać lokalne prefiksy, przez statyczne trasy VPN albo właściwą route table.

W obu wariantach routing musi działać w obie strony. Tunel może być połączony, mimo że ścieżka zwrotna wychodzi przez internet, NAT Gateway albo złą route table.

Utworzyć reguły firewall

Route-based IPsec nie tworzy automatycznie reguł firewall wystarczająco dobrych dla produkcji. Reguły należy tworzyć i logować świadomie.

Zalecane:

1. W Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule utworzyć regułę lokalna-do-AWS: Source zones LAN, Source networks and devices lokalny obiekt sieciowy, Destination zones VPN oraz Destination networks obiekt sieciowy AWS.
2. W Services wybrać tylko wymagane usługi; Any stosować wyłącznie tymczasowo do izolacji problemu, a następnie zastąpić.
3. Kierunek powrotny z Source zones VPN i Destination zones LAN zezwolić tylko wtedy, gdy AWS musi aktywnie osiągać lokalne systemy.
4. Włączyć Log firewall traffic do walidacji.
5. Sprawdzić pozycję reguły przed ogólnymi regułami drop albo catch-all.

Jeżeli oczekiwana reguła nie pasuje, pomaga Reguła Sophos Firewall nie pasuje: jak znaleźć przyczynę.

Sprawdzenie połączenia

Walidacja powinna zawsze obejmować obie platformy i rzeczywisty ruch aplikacyjny. Sam zielony status tunelu nie wystarczy.

Sprawdzić AWS

W AWS sprawdzić:

• VPC > Site-to-Site VPN Connections > Tunnel Details pokazuje oba tunele.
• Status tunelu to UP.
• Przy BGP trasy są widoczne.
• VPC albo Transit Gateway route table zawiera oczekiwane trasy.
• Security groups i NACLs zezwalają na test.
• CloudWatch metrics albo VPN logs nie pokazują powtarzających się problemów IKE lub DPD.

Sprawdzić Sophos Firewall

Na Sophos Firewall sprawdzić:

• Site-to-site VPN > Amazon VPC albo Site-to-site VPN > IPsec pokazuje aktywne tunele.
• Routing > Information > BGP pokazuje sąsiadów i nauczone trasy, jeśli używany jest BGP.
• Network > Interfaces pokazuje interfejsy XFRM.
• Log Viewer pokazuje oczekiwaną regułę firewall.
• Packet Capture potwierdza interfejs wejściowy i wyjściowy, jeśli logi nie wystarczają.

Dobrze wybrać ruch testowy

Test powinien używać konkretnego hosta źródłowego, hosta docelowego i usługi, na przykład ICMP, RDP, SSH, HTTPS albo DNS. Jeżeli ICMP jest blokowany, ping nie jest miarodajny. Lepszy jest test usługi, która będzie faktycznie używana.

Typowe błędy

Błędy AWS VPN często wyglądają jak problemy IPsec, choć przyczyną jest routing albo kontrolki bezpieczeństwa AWS. Poniższe przypadki są szczególnie częste.

Aktywny jest tylko jeden tunel

Jeden tunel wystarczy do pierwszego testu, ale nie do poprawnej pracy produkcyjnej. Oba tunele AWS mają własne endpointy i parametry. Dla każdego tunelu sprawdzić preshared key, parametry IKE/IPsec, interfejs XFRM, sąsiada BGP i status AWS.

BGP nie zestawia się

Jeśli tunel jest połączony, ale BGP nie tworzy peeringu, należy najpierw sprawdzić ASN, IP sąsiada, lokalne ogłoszenia i adresy inside tunnel. Ściśle określony przypadek Sophos występuje wtedy, gdy tunel AWS VPC jest aktywny i połączony na firewallu, sąsiad BGP pozostaje w stanie Active, AWS pokazuje VPN jako down, a IPsec jednocześnie jako up, oraz aktywna konfiguracja BGP zawiera no bgp default ipv4-unicast.

Tylko gdy wszystkie te cechy się zgadzają, należy zapisać bieżącą konfigurację BGP, Local AS i IP sąsiada. Następnie otworzyć konsolę BGP przez 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP i aktywować dokładnie wskazanego sąsiada AWS:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

<as-number> należy zastąpić lokalnym ASN Sophos, a <ip-address> adresem inside tunnel właściwego sąsiada AWS. Następnie ponownie sprawdzić podsumowanie BGP, nauczone i ogłaszane prefiksy, status tunelu AWS oraz rzeczywisty ruch. Jeśli brakuje no bgp default ipv4-unicast albo adresy i numery ASN po stronie AWS się nie zgadzają, nie stosować tych poleceń. Polecenie pochodzi z wąsko określonej procedury SFOS 22 dla problemów z połączeniami Amazon VPC i nie jest ogólną naprawą BGP.

Przed conf t udokumentować bieżącą konfigurację BGP i metodę odzyskiwania zatwierdzoną dla środowiska. Jeśli sąsiad nie osiągnie Established lub znikną istniejące trasy, nie improwizować i użyć wyłącznie tej wcześniej przetestowanej metody. Jeśli jej nie ma, zakończyć diagnostykę przed zmianą i eskalować do Sophos Support.

Tunel zielony, instancja nieosiągalna

Przyczyna często leży poza IPsec: zła AWS route table, brak route propagation, security group, NACL, firewall systemu operacyjnego, zła sieć źródłowa albo brakująca reguła Sophos.

Ścieżka zwrotna idzie źle

AWS musi znać ścieżkę zwrotną do lokalnej sieci przez VPN. Lokalnie powrót do AWS VPC musi iść przez XFRM albo BGP. Routing asymetryczny może wyglądać normalnie w statusie tunelu, ale zrywać realne sesje.

MTU albo fragmentacja psują aplikacje

AWS Site-to-Site VPN i narzut IPsec mogą ujawnić problemy MTU. Jeżeli małe testy działają, ale większe transfery albo konkretne aplikacje wiszą, należy sprawdzić MSS/MTU, fragmentację i packet captures.

Operacje i przegląd

Po uruchomieniu tunel powinien trafić do normalnego procesu operacyjnego. Obejmuje to właściciela, udokumentowany proces preshared-key, okno zmian dla parametrów IPsec, monitoring tuneli, regularne testy failover i jasny proces dla zmian AWS albo ISP.

Przy każdej zmianie VPC CIDR, routingu Transit Gateway, route tables, security groups, lokalnych sieci albo ogłoszeń BGP należy powtórzyć walidację VPN. Cloud VPN nie jest jednorazowym kliknięciem, tylko częścią architektury sieci.

Wycofać nowe tunele i trasy w sposób ukierunkowany

Przed zmianą zabezpieczyć backup, profile IPsec i przypisanie tuneli, adresy XFRM, sąsiadów i ogłoszenia BGP, reguły firewall oraz AWS Route Tables wraz z propagacją. Przy nieoczekiwanych ogłoszeniach, nieprawidłowym celu lub przerwaniu istniejącego ruchu najpierw wycofać nowo wprowadzone prefiksy albo wyłączyć nowe połączenie i przywrócić do udokumentowanego bezpiecznego stanu tylko zmienione reguły i trasy. Nie usuwać ani nie resetować przy tym istniejących sąsiadów BGP, globalnego ASN ani współdzielonych bram/VPC/subnetów. Ponownie sprawdzić przewidziane istniejące trasy, dozwolone aplikacje i blokowanie niedozwolonego źródła. Bez zatwierdzonej ścieżki powrotnej zatrzymać zmianę przed aktywacją. Na potrzeby tego artykułu nie przeprowadzono odtworzenia, failover ani testu w środowisku klienta AWS.

FAQ