Som standard venter en AWS Site-to-Site VPN på, at customer gateway starter forhandlingen. Den standard er en indstilling, ikke en lov, og indstillingen hedder Startup action. Før du rækker ud efter den, skal du skille to spørgsmål ad, som konstant bliver blandet sammen: hvem etablerer tunnelen, og om de pakker, du er interesseret i, har en rute igennem den. Kun det første spørgsmål findes i tunnelindstillingerne.

Adskil starthandling fra DPD-timeout-handling

To indstillinger pr. tunnel styrer to forskellige hændelser, og når du sætter den ene, siger det intet om den anden.

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

Hvis AWS skal rejse en ny eller ændret tunnel, vælg start. Hvis AWS også skal genstarte forhandlingen efter en DPD-timeout, skal du konfigurere restart for den hændelse separat. Ingen af indstillingerne er en genforsøgspolitik for applikationen, og ingen af dem er et nøgleskiftsinterval: DPD kontrollerer, om partneren er i live, mens nøgleskift udskifter security associations på en aktiv tunnel.

En applikation, der får timeout, mens tunnelen stadig rapporterer up, har et datastiproblem. At forkorte DPD-timeren løser det ikke, og det kan give ekstra uro, som du skal forklare senere.

Kontroller, at AWS har et sted at sende forhandlingen hen

Initiering fra AWS-siden virker kun med IKEv2, og AWS skal bruge customer gatewayens offentlige adresse for at vide, hvor forslaget skal sendes hen. Det tilfælde, der gør ondt, er en certifikatgodkendt customer gateway-ressource oprettet uden en adresse: AWS dokumentation beskriver, at man opretter en ny customer gateway-ressource med adressen og derefter ændrer VPN-forbindelsen til at pege på den.

Et certifikat beviser, hvem partneren er. Det fortæller ikke AWS, hvor partneren er, og det er to forskellige krav. Derfor er løsningen en ny customer gateway-ressource og ikke et nyt certifikat. At udskifte certifikatet efterlader AWS med den samme manglende destination.

Hvis customer gatewayen sidder bag NAT, skal AWS også have en konfigureret responder identity, IDr, så partnerens identitet passer til det, enheden forventer. Bekræft den værdi og den firewallvej, der lukker IKE-trafik igennem, før du giver indstillingen, du netop har ændret, skylden. At vælge start kan ikke få en partner, der ikke kan nås eller er forkert identificeret, til at acceptere et forslag.

Anvend ændringen på én tunnel, og forvent en afbrydelse

En VPN-forbindelse har to tunneler med uafhængige indstillinger, så bekræft ud fra dens udvendige adresse, hvilken du redigerer. AWS tillader at ændre én tunnel ad gangen, og forbindelsen over den valgte tunnel kan blive afbrudt i flere minutter.

  1. Vælg Site-to-Site VPN-forbindelsen, og åbn Modify VPN tunnel options.
  2. Vælg tunnelen efter udvendig IP-adresse, og bekræft dens IKE-version og customer gateway-ressource.
  3. Sæt de start- og DPD-handlinger, du faktisk ønsker, og gem derefter i et vindue, du selv kontrollerer.
  4. Bekræft, at den ændrede tunnel etableres, og kontroller den anden tunnel og rutingen før næste ændring.

Én adfærd fortjener opmærksomhed før vedligeholdelse. Når AWS-initiering er slået til, er der ingen timeout: AWS bliver ved, indtil tunnelen kommer op, og det starter forfra, når customer gatewayen sender en delete-SA-besked. Hvis du tager partneren ned med vilje, bliver AWS ved med at banke på, og partnerens logfiler vil vise det.

Verificer applikationens vej, ikke kun tunnelens tilstand

En tunnel, der rapporterer up, er ikke det samme som en anmodning, der virker. En Lambda-funktion, der er knyttet til en VPC, har stadig brug for en subnet-rute til kundens præfiks, security group- og network ACL-regler, der tillader trafikken, navneopslag, der returnerer den rigtige adresse, og en returvej på kundens side.

Test én gang med en rigtig anmodning fra applikationens kontekst, og læs derefter flow logs, hvis den fejler. Keepalive-trafik er en legitim mulighed, når AWS-initiering er slået fra, og en tomgangstunnel har brug for pakker for at blive oppe, men det bør være en overvågningsbeslutning, du kan navngive, ikke en uforklarlig ping-løkke boltet på en funktion.

Vælg først, hvem der etablerer tunnelen, og diagnosticér derefter den resterende fejl i dens eget lag. AWS-dokumentationen om initiering dækker kravene til adresse, identitet og genforsøg mere detaljeret, end konsolthintene gør.

Relaterede artikler