Anslut Sophos Firewall till AWS Site-to-Site VPN

En AWS Site-to-Site VPN ansluter ett lokalt nät bakom Sophos Firewall till en AWS VPC eller Transit Gateway. Tekniskt är det en IPsec-VPN, men operativt skiljer den sig från en vanlig Sophos-till-Sophos-tunnel: AWS skapar två tunnlar per VPN-anslutning, använder Customer Gateway och målgateway-objekt, och routing beror starkt på om statiska routes eller BGP används.

Den här artikeln beskriver den praktiska uppsättningen med Sophos Firewall och AWS. Den kompletterar den allmänna guiden Konfigurera Sophos Firewall Site-to-Site IPsec VPN med AWS-specifika fallgropar: två tunnlar, BGP-neighbours, route tables, security groups, NACLs och statuskontroller i AWS och Sophos. Om tunneln redan är uppe men trafiken inte går igenom passar Sophos Firewall IPsec VPN troubleshooting bättre.

När artikeln passar

Artikeln passar när ett kontor, datacenter eller lokalt nät ska anslutas till AWS via Sophos Firewall. Den täcker AWS Site-to-Site VPN till en VPC, Virtual Private Gateway eller Transit Gateway. Den täcker inte Sophos Firewall som virtuell appliance direkt i AWS.

Typiska scenarier:

• lokalt servernät till EC2-instanser i en VPC
• backup-, övervaknings- eller managementtrafik till AWS
• hybrid-DNS, AD, jump hosts eller administrationsnät
• migrering från statisk VPN till dynamisk BGP-routing
• redundant drift med två AWS-tunnlar

AWS och Sophos använder olika termer. I AWS arbetar man med Customer Gateway, Virtual Private Gateway eller Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups och Network ACLs. På Sophos Firewall handlar det om Amazon VPC-anslutningar, IPsec-profiler, XFRM-interfaces, BGP, routes och firewallregler.

Planera före konfigurering

AWS Site-to-Site VPN bör inte behandlas som bara import av en nedladdad exempelkonfiguration. AWS-filen är användbar, men produktionsgodkännande beror på routing, security groups, NACLs, firewallregler och tester med verklig trafik.

Definiera nät och målgateway

Först måste det vara klart vilken AWS-sida som ska användas:

• Virtual Private Gateway för en klassisk enskild VPC.
• Transit Gateway för flera VPC:er, flera platser eller en större routingdesign.
• Cloud WAN eller andra varianter endast när AWS-arkitekturen uttryckligen kräver det.

Dokumentera i förväg:

• AWS VPC CIDR, till exempel 10.60.0.0/16
• relevanta AWS subnets och route tables
• lokala nät bakom Sophos Firewall, till exempel 172.16.20.0/24
• publik IP för Sophos Firewall eller upstream-router
• routingläge: static eller dynamic BGP
• lokal och AWS-ASN om BGP används
• förväntade testmål på båda sidor
• planerade tunnel options, IKE-version, preshared keys och lifetimes

Överlappande nät bör rensas upp innan VPN-designen byggs. NAT över IPsec kan fungera, men gör route tables, security groups, loggar och senare felsökning svårare.

Ta båda tunnlarna på allvar

AWS skapar två tunnlar per Site-to-Site VPN connection, var och en med en egen AWS-endpoint. Båda tunnlarna bör konfigureras och kontrolleras på Sophos Firewall. Att bara bygga en tunnel är bekvämt i labb, men i produktion går AWS-redundansen förlorad.

Förväntan måste vara rätt: returvägen från AWS föredrar en tunnel beroende på routing och AWS-sida, och kan växla vid fel. Det betyder inte att båda tunnlarna alltid används jämnt. Det viktiga är att båda tunnlarna kommer upp, att BGP eller statiska routes är korrekta och att failover har testats.

Statisk routing eller BGP

AWS Site-to-Site VPN stöder statiska routes och dynamisk routing med BGP. BGP är oftast bättre när flera prefix, framtida utbyggnad eller Transit Gateway ingår. Statiska routes är enklare, men varje nätändring måste underhållas manuellt.

I praktiken:

• BGP behöver matchande ASN-värden på båda sidor.
• Sophos Firewall måste annonsera avsedda lokala prefix.
• AWS route tables måste faktiskt använda propagated eller statiska routes.
• Security groups och NACLs måste också tillåta trafiken.
• Identiska statiska och BGP-routes kan ge oväntad prioritet.

Förbered AWS

Följande steg beskriver det vanliga flödet. Detaljer skiljer sig mellan Virtual Private Gateway och Transit Gateway, men principen är densamma.

Skapa Customer Gateway

Customer Gateway beskriver den lokala Sophos-sidan i AWS.

Ange:

1. Gå i AWS-konsolen till VPC > Virtual private network (VPN) > Customer gateways och välj Create customer gateway.
2. Ange Name tag, till exempel cgw-sophos-hq.
3. Om BGP ska användas anger du exakt lokal Sophos-ASN under BGP ASN. AWS visar fältet även för anslutningar med statisk routing, men statisk routing etablerar ingen BGP-peering.
4. Ange Sophos-sidans statiska, internetnåbara adress under IP address. Om brandväggen står bakom en NAT-enhet anges NAT-enhetens publika IP-adress för AWS Customer Gateway, inte adressen till Sophos-brandväggens WAN-interface.
5. Ange eventuellt ett tydligt namn under Device och välj Create customer gateway.

Om Sophos Firewall står bakom en router eller operatörsutrustning måste det vara klart vilken publik IP AWS ser och om NAT-T fungerar korrekt. Enligt AWS-alternativen för Customer Gateway måste UDP 500 och, när NAT-T används, UDP 4500 tillåtas mellan det lokala nätverket och AWS Site-to-Site VPN-endpoints. Konfigurera NAT-/brandväggsenheten framför Sophos så att dessa portar tillåts och vidarebefordras mellan Sophos-brandväggens WAN-interface och adresserna till båda AWS-tunnelendpoints i konfigurationsfilen; se de direkta AWS-brandväggsreglerna.

Skapa eller välj målgateway

För en enskild VPC skapas normalt en Virtual Private Gateway under VPC > Virtual private network (VPN) > Virtual private gateways och kopplas med Actions > Attach to VPC. Större AWS-miljöer använder ofta en Transit Gateway.

Kontrollera:

• Gateway är kopplad till rätt VPC eller Transit Gateway.
• AWS-side ASN krockar inte med Sophos-ASN.
• Route tables för VPC eller Transit Gateway är planerade.
• Subnets som används för test använder rätt route table.

Skapa Site-to-Site VPN connection

Gå därefter till VPC > Virtual private network (VPN) > Site-to-Site VPN connections och välj Create VPN connection. Den aktuella AWS-proceduren beskriver samma resurser och vilka värden som beror på designen.

Viktiga punkter:

• Välj planerad Virtual Private Gateway eller Transit Gateway under Target gateway type.
• Välj Existing och tidigare skapad Customer Gateway under Customer gateway.
• Sätt Routing options till Dynamic (requires BGP) eller Static; ange under Static IP prefixes endast de lokala prefix som AWS ska nå via VPN.
• Granska Tunnel Options medvetet, särskilt IKE version, encryption, integrity, DH/PFS och DPD.
• Dokumentera preshared keys per tunnel eller låt AWS generera dem avsiktligt.

För dynamisk routing kräver Sophos att Local IPv4 Network Cidr och Remote IPv4 Network Cidr i AWS-anslutningen båda anges som 0.0.0.0/0, så att BGP-peering kan etableras. Om ett Local AS redan är konfigurerat på brandväggen ska exakt detta ASN anges för AWS Customer Gateway.

Välj Download configuration efter skapandet. För automatisk Sophos-import väljer du Vendor Sophos, Platform Sophos Firewall, Software v19+ och den faktiskt planerade IKE version. Filen är endast en exempelkonfiguration: algoritmer, DH-grupper, certifikat och IP-familj måste passa produktionsdesignen. Bakom NAT ska den lokala adressen till Sophos WAN-interface anges före importen i båda tunnel_outside_address-blocken på customer-gateway-sidan. Lämna Outside-endpoints på AWS-sidan oförändrade; ersätt inte generellt alla XML-block med samma namn. I AWS Customer Gateway ska däremot den framförliggande NAT-enhetens publika adress finnas kvar. För statiska routes väljer du Generic och konfigurerar manuellt. Även dynamisk BGP kan byggas manuellt med den Generic-nedladdning som beskrivs nedan; Sophos-importen är inte den enda vägen för BGP.

Kontrollera route tables, security groups och NACLs

En grön VPN-tunnel i AWS betyder ännu inte att en EC2-instans kan nås.

För verifiering, kontrollera:

• VPC route table har en route till det lokala nätet via Virtual Private Gateway eller Transit Gateway.
• Vid Virtual Private Gateway är route propagation aktiverad eller routen statiskt satt.
• Transit Gateway route tables innehåller rätt attachments och propagations.
• Security group för mål-instansen tillåter önskad trafik från det lokala nätet.
• Network ACLs tillåter fram- och returväg.
• Instansens operativsystems-firewall blockerar inte testet.

Detta missas ofta, eftersom Sophos och AWS båda kan visa en ansluten tunnel även om instansen inte svarar på grund av security group eller returroute.

Konfigurera Sophos Firewall

Sophos erbjuder två praktiska vägar för AWS: import via Site-to-site VPN > Amazon VPC eller manuell konfigurering som route-based IPsec-anslutning. För många AWS-upplägg är import den renaste starten, men de skapade objekten måste ändå kontrolleras.

Importera AWS-konfigurationen

Under Site-to-site VPN > Amazon VPC kan Sophos Firewall importera anslutningen med Use AWS security credentials eller Use VPC configuration file. För credentialmetoden används en separat AWS IAM-användare med de behörigheter som krävs för Site-to-Site VPN-inställningarna; access key och secret key skyddas och roteras som andra administrativa hemligheter.

Importen är en ögonblicksbild. Om tunnelalternativ eller andra anslutningsvärden ändras i AWS måste inställningarna importeras på nytt och därefter valideras fullständigt. En tidigare import följer inte AWS-konfigurationen automatiskt.

Följande procedur använder den nedladdade AWS-konfigurationsfilen:

Steg:

1. Öppna Sophos Firewall.
2. Gå till Site-to-site VPN > Amazon VPC.
3. Välj Use VPC configuration file.
4. Ladda upp AWS-konfigurationsfilen.
5. Starta importen.
6. Kontrollera skapade anslutningar, IPsec-profiler, XFRM-interfaces och BGP-inställningar.

Importen skapar IPsec-profiler, BGP-inställningar och XFRM-interfaces. Lägg därefter till de lokala prefixen under Routing > BGP > Networks. Under Administration > Device access måste IPsec vara aktiverat för WAN och Dynamic Routing för VPN. Dessa inställningar tillåter tunnelns och routingens kontrolltrafik; de ersätter inte en brandväggsregel för nyttotrafiken.

Bakom NAT ska du i vart och ett av de två tunnelavsnitten kontrollera att tunnel_outside_address på customer-gateway-sidan innehåller den lokala Sophos-WAN-adressen. Ändra inte Outside-adresser på AWS-sidan; den publika NAT-adressen förblir AWS-Customer-Gateway-adressen. Aktivera inte filen och importobjekten om mappningen är oklar, utan identifiera först kundsidan och AWS-sidan entydigt.

Bygg två IPv4-VGW-tunnlar manuellt med BGP

Detta alternativ beskriver en IPv4-anslutning till en Virtual Private Gateway kopplad till VPC:n med Dynamic (requires BGP). Det är ingen runbook för IPv6/Transit Gateway/Cloud WAN och inget generellt påstående om att AWS inte stöder IPv6. AWS-behörigheter, lokala administratörsrättigheter, nåbara Outside-endpoints, icke överlappande nät och en godkänd återställningsväg är förutsättningar. Aktivera inte importen och en manuell parallell uppsättning samtidigt för samma routes.

1. Öppna Download configuration för den avsedda VPN-anslutningen i AWS: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Detta gäller uttryckligen även manuell dynamisk BGP. Filen innehåller PSK:er: förvara den krypterat och med begränsad åtkomst.
2. Dokumentera Outside-endpoint, PSK, Inside-CIDR, Customer-Inside-adress, AWS-Inside-adress och ASN:er separat för varje tunnel från den faktiskt genererade konfigurationen. Använd två olika /30-nät ur 169.254.0.0/16 som AWS accepterar; använd inte reserverade eller redan använda områden. Följande mappning är ett läsbart planeringsexempel, inte en tilldelning från AWS:

Mappningstabell: Outside-IP etablerar IPsec; Inside-IP adresserar XFRM och BGP. Använd endast de adresser som AWS faktiskt har tilldelat: dra inte slutsatser om den egna tilldelningen utifrån demo-adressernas ordning. SFOS-XFRM-adressen är Customer-Inside-adressen, aldrig AWS-Inside-adressen eller den publika IP-adressen. BGP-neighbourn är AWS-Inside-adressen, inte Outside-endpointen.

3. Skapa en entydigt namngiven anpassad profil under Profiles > IPsec profiles > Add. Ett avgränsat exempel för tunnlar som konfigurerats så på båda sidor är IKEv2, fas 1 AES256 / SHA2 256 / DH 14 (DH2048) och fas 2 AES256 / SHA2 256 / PFS 14 (DH2048). Aktivera Re-key connection; använd Key negotiation tries 0 och inaktiverad Use strict profile endast om den godkända driftplanen föreskriver det. De valda algoritmerna och DH/PFS-grupperna måste bilda en gemensam tillåten proposal, inte bara ha samma profilnamn.
4. Dokumentera lifetimes och Rekey/DPD separat. Ett historiskt exempel anger AWS fas 1 28800 sekunder, men SFOS Key life 28000; fas 2 3600 på båda sidor, Rekey Margin 360 och Fuzz 50 procent. Olika lokala IKEv2-Rekey-timers är inte automatiskt ett proposal-fel och inget bevis för testad interoperabilitet. Använd inte en motsägelsefull timer som universell standard utan att påpeka motsägelsen: använd de faktiskt konfigurerade AWS-värdena och en tillhörande godkänd SFOS-Rekey-plan; stoppa och klargör om villkoren är oklara. Ett DPD-exempel är AWS Restart samt aktiverad SFOS DPD, kontrollintervall 30, svarsväntetid 120 sekunder och Re-initiate. Dessa värden är ett profilexempel som ska kontrolleras, ingen universell föreskrift. Bekräfta Rekey-/DPD-beteendet i det egna ändringsfönstret före produktionsdrift.
5. Skapa en egen anslutning för varje tunnel under Site-to-site VPN > IPsec > Add med Connection type Route-based (Tunnel interface), IP version IPv4 och Gateway type Initiate the connection. Välj den nyss kontrollerade anpassade profilen under Profile, inte blint någon annan standardprofil med namnet IKEv2. Ange Authentication type Preshared key och exakt denna tunnels PSK. Listening interface är det lokala WAN-interfacet; Gateway address är respektive AWS-Outside-endpoint. Ange Local/Remote IKE IDs endast enligt den faktiskt förväntade identitetsplanen, använd aldrig slumpmässiga IP-adresser; bakom NAT är den lokala WAN-adressen inte samma som den publika Customer-Gateway-adressen. Välj Activate on save först efter granskning i det godkända fönstret; spara och aktivera båda anslutningarna.
6. Öppna det XFRM som hör till respektive anslutning under Network > Interfaces och kontrollera anslutningslänken. Ange denna tunnels Customer-Inside-IP och /30 (255.255.255.252) under IPv4/netmask. Använd det andra XFRM-interfacets egen Inside-IP för det; förväxla inte mappningarna.
7. Behåll det Local AS som redan används under Routing > BGP > Global configuration, eller ange den godkända Customer-Gateway-ASN:n. Använd ett unikt, stabilt Router ID från den egna planen. Skriv inte över ett befintligt globalt ASN för detta VPN; AWS måste använda samma lokala ASN-värde. Kopiera inte ett ASN-intervall eller demo-ASN utan kontroll: kontrollera först tillgänglighet, tillåtlighet i AWS och konfliktfrihet. Skapa en IPv4-neighbor för varje AWS-Inside-IP under Neighbors, med Remote AS lika med den faktiska VGW-ASN:n.
8. Annonsera endast de godkända lokalt nåbara prefixen under Routing > BGP > Networks. Tillåt IPsec för WAN och Dynamic Routing för VPN under Administration > Device access; lägg inte till en generell LAN-tillåtelse om ingen lokal routing-peer är avsedd där. Att öppna BGP TCP 179 som nyttotrafik för hela världen eller mellan alla LAN/VPN-nät ersätter inte denna control-plane-tillåtelse. Skapa dessutom de snävt avgränsade dataregler som beskrivs i följande avsnitt.
9. Kontrollera Established samt förväntade inlärda och annonserade prefix för varje neighbor under Routing > Information > BGP > Neighbors. Kontrollera i AWS under Tunnel Details att båda tunnlarna är UP samt BGP-routes; kontrollera VGW-route-propagation för berörda subnets Route Tables. Testa först därefter tillåten applikationstrafik och en otillåten källa. Inaktivera en tunnel kontrollerat inom det överenskomna fönstret, kontrollera att förväntad route/applikation fungerar vidare över den andra, aktivera tunneln igen och kontrollera båda grannrelationerna på nytt; hävda inte att redundansen har godkänts utan ett faktiskt failover-test.

Vid IPsec-fel ska endpoint, PSK, proposals, IDs och NAT-T kontrolleras först för varje tunnel; vid BGP Active kontrolleras först XFRM-Inside-adresser, ASN, peer-aktivering och Device Access. En provisorisk statisk route med ping är ingen generell BGP-reparation och kan dölja fel väg. Om befintliga routes försvinner eller Lifetime-/ID-mappningen är oklar ska inga ytterligare värden provas, utan den nya konfigurationen stoppas och jämföras med det säkrade läget. Detta är en dokumentbaserad, avgränsad anvisning som inte har testats på enheten här.

Kontrollera IPsec-profil och tunnlar

Efter import, eller vid manuell konfigurering, bör man inte lita blint på statusen.

Kontrollera:

• Båda AWS-tunnlarna finns.
• IKE-versionen matchar AWS-konfigurationen.
• Encryption, Authentication, DH Group och PFS bildar för varje tunnel ett förhandlingsförslag som tillåts på båda sidor; Lifetimes och lokala rekey-timers kontrolleras separat mot den godkända planen och bedöms inte enbart utifrån numerisk överensstämmelse.
• Preshared key är korrekt per tunnel.
• Gateway type och remote gateway pekar på respektive AWS-tunnelendpoint.
• XFRM-interfaces finns och är tydligt namngivna.

Om AWS-tunnelalternativen ändras måste Sophos förhandlingsförslag fortfarande vara kompatibla och de separat dokumenterade rekey-/DPD-timers stämma med den godkända driftplanen. Ensidiga ändringar av algoritm, DH/PFS, PSK eller identitet kan förhindra fas 1 eller fas 2; olika lokala IKEv2-lifetimes är i sig inte belägg för ett sådant fel i förhandlingsförslagen.

Konfigurera BGP eller statiska routes

Med BGP kontrolleras under Routing > BGP att lokal ASN, neighbour, remote ASN och annonserade nät stämmer. Den fullständiga konfigurationen och verifieringen förklaras i Konfigurera BGP i Sophos Firewall. Under Routing > Information > BGP bör Neighbors, Summary och Routes visa förväntade värden.

Med statisk routing måste routes till AWS-nät peka mot rätt XFRM-interface. AWS måste också känna till lokala prefix, antingen via statiska VPN-routes eller via rätt route table.

För båda varianterna måste routing fungera i båda riktningar. En tunnel kan vara ansluten medan returvägen går via internet, NAT Gateway eller fel route table.

Skapa firewallregler

Route-based IPsec skapar inte automatiskt produktionsregler som är tillräckligt precisa. Skapa och logga reglerna medvetet.

Rekommenderat:

1. Skapa under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule regeln lokalt-till-AWS: Source zones LAN, Source networks and devices det lokala nätverksobjektet, Destination zones VPN och Destination networks AWS-nätverksobjektet.
2. Välj under Services endast nödvändiga tjänster; använd Any bara tillfälligt för felsökning och ersätt det därefter.
3. Tillåt den motsatta riktningen med Source zones VPN och Destination zones LAN endast om AWS aktivt måste nå lokala system.
4. Aktivera Log firewall traffic för verifiering.
5. Kontrollera regelposition före breda drop- eller catch-all-regler.

Om den förväntade regeln inte matchar hjälper Sophos Firewall-regel matchar inte: så hittar man orsaken.

Verifiera anslutningen

Verifiering bör alltid omfatta båda plattformarna och verklig applikationstrafik. En grön tunnelstatus räcker inte.

Kontrollera AWS

I AWS, kontrollera:

• VPC > Site-to-Site VPN Connections > Tunnel Details visar båda tunnlarna.
• Tunnelstatus är UP.
• Vid BGP är routes synliga.
• VPC- eller Transit Gateway-route table innehåller förväntade routes.
• Security groups och NACLs tillåter testet.
• CloudWatch metrics eller VPN logs visar inga återkommande IKE- eller DPD-problem.

Kontrollera Sophos Firewall

På Sophos Firewall, kontrollera:

• Site-to-site VPN > Amazon VPC eller Site-to-site VPN > IPsec visar aktiva tunnlar.
• Routing > Information > BGP visar neighbours och inlärda routes om BGP används.
• Network > Interfaces visar XFRM-interfaces.
• Log Viewer visar förväntad firewallregel.
• Packet Capture bekräftar ingående och utgående interface när loggar inte räcker.

Välj testtrafik noggrant

Ett test bör använda en konkret source host, target host och service, till exempel ICMP, RDP, SSH, HTTPS eller DNS. Om ICMP blockeras säger ping lite. Bättre är att testa tjänsten som faktiskt ska användas.

Vanliga fel

AWS VPN-fel ser ofta ut som IPsec-problem, även när routing eller AWS security controls är orsaken. Följande fall är särskilt vanliga.

Endast en tunnel är aktiv

En tunnel räcker för ett första test, men inte för ren drift. Båda AWS-tunnlarna har egna endpoints och parametrar. Kontrollera preshared key, IKE/IPsec-parametrar, XFRM-interface, BGP-neighbour och AWS-status per tunnel.

BGP kommer inte upp

Om tunneln är ansluten men BGP-peering inte etableras kontrolleras först ASN, neighbour-IP, lokala annonseringar och inside tunnel-adresser. Ett snävt avgränsat Sophos-fall föreligger när AWS VPC-tunneln är aktiv och ansluten på brandväggen, BGP-neighbour förblir i Active, AWS visar VPN som down medan IPsec är up och den aktiva BGP-konfigurationen innehåller no bgp default ipv4-unicast.

Endast när alla dessa kännetecken stämmer dokumenteras den aktuella BGP-konfigurationen, Local AS och neighbour-IP. Öppna därefter BGP-konsolen via 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP och aktivera exakt den berörda AWS-neighbour:

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

Ersätt <as-number> med det lokala Sophos-ASN och <ip-address> med inside tunnel-adressen för berörd AWS-neighbour. Kontrollera därefter BGP-summary, inlärda och annonserade prefix, AWS-tunnelstatus och verklig trafik igen. Om no bgp default ipv4-unicast saknas eller AWS-adresserna och ASN inte stämmer ska kommandona inte användas. Kommandot kommer från den snävt avgränsade SFOS 22-proceduren för problem med Amazon VPC-anslutningar och är ingen generell BGP-reparation.

Dokumentera aktuell BGP-konfiguration och den återställningsmetod som godkänts för miljön före conf t. Om neighbourn inte når Established eller befintliga routes försvinner ska du inte improvisera, utan endast använda den i förväg testade metoden. Om en sådan metod saknas avslutas diagnosen före ändringen och eskaleras till Sophos Support.

Tunnel grön, instans inte nåbar

Orsaken ligger ofta utanför IPsec: fel AWS route table, saknad route propagation, security group, NACL, operativsystems-firewall, fel sourcenät eller saknad Sophos-firewallregel.

Returvägen går fel

AWS måste känna till returvägen till det lokala nätet via VPN. Lokalt måste returvägen till AWS VPC gå via XFRM eller BGP. Asymmetrisk routing kan se normal ut i tunnelstatus men bryta verkliga sessioner.

MTU eller fragmentering stör applikationer

AWS Site-to-Site VPN och IPsec-overhead kan synliggöra MTU-problem. Om små tester fungerar men större överföringar eller vissa applikationer hänger, kontrollera MSS/MTU, fragmentering och packet captures.

Drift och review

Efter driftsättning bör tunneln flyttas in i normal drift. Det omfattar owner, dokumenterad process för preshared keys, change window för IPsec-parametrar, tunnelövervakning, regelbundna failover-tester och ett tydligt flöde vid AWS- eller ISP-ändringar.

Vid varje ändring av VPC-CIDR, Transit Gateway-routing, route tables, security groups, lokala nät eller BGP-annonseringar bör VPN-verifieringen upprepas. Cloud VPN är inte ett engångsklick, utan en del av nätverksarkitekturen.

Återställ nya tunnlar och routes riktat

Säkra backup, IPsec-profiler och tunnelmappning, XFRM-adresser, BGP-neighbors/annonseringar, brandväggsregler och AWS-Route-Tables inklusive propagation före ändringen. Vid oväntade annonseringar, fel mål eller avbruten befintlig trafik ska de nyinförda prefixen först dras tillbaka respektive den nya anslutningen inaktiveras, och endast de ändrade reglerna/routes återställas till det dokumenterade säkra läget. Radera eller återställ inte befintliga BGP-neighbors, det globala ASN:t och delade gateways/VPC:er/subnet. Kontrollera avsedda befintliga routes, tillåtna applikationer och blockeringen av en otillåten källa på nytt. Stoppa ändringen före aktivering om en godkänd återställningsväg saknas. Ingen återställning, failover eller AWS-tenant-test har utförts för denna artikel.

FAQ