Nu beschikbaar: Open WireGuard-endpoints en asynchrone Lambda-aanroeping

Open WireGuard-endpoints

WireGuard Listeners vereisten altijd dat elke verbindende client vooraf was geregistreerd: u vermeldt de publieke sleutel van elke peer in uw CloudFormation-template, waarna de Listener elke handshake van een onbekende sleutel weigert. Dit model is geschikt voor private services met een beheerd set apparaten, maar het vormt een probleem voor alles wat toegankelijk moet zijn voor een grote of onbekende set clients.

Denk hierbij aan een mobiele app die bij de eerste start een WireGuard-sleutelpaar genereert, of een vloot apparaten die on-demand worden geprovisioneerd waarbij centraal sleutelbeheer operationeel onpraktisch is. Ook voor elke publiek toegankelijke service waar clients die u nog nooit heeft gezien verbinding moeten maken, is dit problematisch. Met het vorige model vereiste elke client een registratiestap buiten de band en een CloudFormation-update voordat de handshake kon worden voltooid. Dat is geen model dat schaalt voor publieke services.

De nieuwe eigenschap AllowUnknownPeers heft deze beperking op. Wanneer u deze op true zet bij een WireGuard Listener, zal de Gateway de handshake voltooien met elke geldige WireGuard-client, ongeacht of de publieke sleutel is vermeld. De verbinding blijft volledig versleuteld — de cryptografische eigenschappen van WireGuard veranderen niet. Het verschil is simpelweg dat de Listener de sleutel niet langer vooraf hoeft te kennen.

De analogie met HTTPS is bewust gekozen. Wanneer u een website bezoekt via HTTPS, hoeft de server niet te weten wie u bent voordat er een versleutelde verbinding wordt tot stand gebracht. De TLS-handshake wordt voltooid, het kanaal wordt versleuteld, en authenticatie (indien die überhaupt plaatsvindt) is een aparte kwestie op de applicatielaag. Open WireGuard-endpoints werken op dezelfde manier: het transport is versleuteld, en de identiteit kan door uw Lambda- of Step Functions-bestemming worden afgehandeld zoals uw applicatie dat vereist.

Toevoegen van een gedeelde credential gate

Volledig open inschrijving — het accepteren van letterlijk elke WireGuard-client — is passend voor sommige services. Voor andere services wilt u wel de versleuteling en de open handshake, maar wilt u ook verbindingen van clients die geen inloggegevens hebben gekregen, voorkomen. De eigenschap UnknownPeerPreSharedKey biedt een lichtgewicht poort voor precies dit scenario.

Wanneer UnknownPeerPreSharedKey is ingesteld, moeten onbekende peers die PSK (Pre-Shared Key) opnemen in hun WireGuard-configuratie, anders mislukt de handshake. Dit is geen authenticatie per apparaat — elke client gebruikt hetzelfde geheim — maar het beperkt de toegang significant tot clients die de PSK hebben ontvangen. Zie het als een gedeelde API-sleutel voor toegang op transportlaag: geen sterke identiteitscontrole, maar een reële barrière tegen willekeurige verbindingen van clients die nooit inloggegevens hebben gekregen.

Het distribueren van de PSK aan clients is de verantwoordelijkheid van uw applicatie. Bewaar deze in AWS Secrets Manager en verwijs ernaar vanuit uw CloudFormation-stack aan de infrastructuurzijde; provisioneer deze naar apparaten tijdens de productie of inschrijving aan de clientzijde.

Voorbeeldconfiguratie:

WireGuardListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Protocols:
      - wg
    AllowUnknownPeers: true
    UnknownPeerPreSharedKey: !Sub "{{resolve:secretsmanager:${WireGuardPSK}:SecretString}}"
    Destinations:
      - Name: packet-handler
        DestinationArn: !GetAtt HandlerLambda.Arn
    Role:
      Arn: !GetAtt ProxylityRole.Arn

Genoemde peers (vermeld in het Peers array) worden niet beïnvloed door AllowUnknownPeers en UnknownPeerPreSharedKey. Zij gebruiken zoals voorheen hun eigen per-peer SharedSecret. De twee modellen kunnen naast elkaar bestaan op één Listener: een vaste set bekende apparaten met per-apparaat PSK's, en een open slot voor dynamische clients achter een gedeelde credential.

Asynchrone Lambda-aanroeping (Async Invocation)

Lambda-bestemmingen in UDP Gateway hebben altijd gebruikgemaakt van synchrone RequestResponse-aanroeping: de Gateway levert een batch pakketten, wacht tot de functie is voltooid en gebruikt de retourwaarde van de functie om antwoordpakketten terug te sturen naar clients. Dit model is de standaard om aan te sluiten bij hoe UDP request/response-patronen werken.

Echter, synchrone aanroeping wordt beperkend voor workloads waarbij de taak van een functie is om een proces te starten dat langer duurt dan een enkele aanroeping. Lambda durable functions lossen dit precies op: via een checkpoint-and-replay-mechanisme kan een durable function tot een jaar lang worden uitgevoerd, waarbij hij na fouten automatisch wordt hervat zonder voortgang te verliezen. Het aanroepingstype Event is hier het juiste leveringsmodel — de Gateway vuurt de pakketbatch af en gaat verder, terwijl de durable uitvoering onafhankelijk doorgaat.

Het nieuwe argument UseAsyncInvoke wijzigt het aanroepingstype naar de Event-modus van Lambda. De Gateway levert de pakketbatch en ontvangt onmiddellijk een HTTP 202 Accepted zonder te wachten tot de functie is voltooid. Er wordt geen antwoord teruggestuurd naar de UDP-client. De functie wordt onafhankelijk van de request-lifecycle van de Gateway uitgevoerd.

Het primaire gebruiksdoel is het triggeren van durable workloads. Een functie die is aangeroepen met UseAsyncInvoke ontvangt de inkomende pakketbatch, start een durable uitvoering (of stuurt deze door naar Step Functions als u dat orchestratiemodel verkiest) en keert onmiddellijk terug. De externe client stuurde een UDP-pakket; er draait nu een langlopende, fouttolerante workflow in zijn naam, met checkpointed voortgang en automatisch herstel van fouten — zonder dat de Gateway hiervoor een verbinding open hoeft te houden.

Voorbeeldconfiguratie:

Destinations:
  - Name: workflow-trigger
    DestinationArn: !GetAtt WorkflowTriggerLambda.Arn
    Role:
      Arn: !GetAtt ProxylityRole.Arn
    Arguments:
      UseAsyncInvoke: "true"

Houd bij het gebruik van asynchrone aanroeping rekening met de volgende punten:

  • Geen antwoorden: De retourwaarde van de functie wordt genegeerd. Als een pakket een antwoord nodig heeft, is asynchrone aanroeping het verkeerde instrument — gebruik in dat geval standaard synchrone aanroeping of response streaming.
  • AWS-retries bij fouten: Lambda zal een mislukte asynchrone aanroeping automatisch tot twee keer opnieuw proberen. Zorg ervoor dat uw functie (en elke downstream workflow die deze start) idempotent is, of configureer een dead-letter queue om fouten vast te leggen zonder dat er stilzwijgend dataverlies optreedt.
  • Wederzijdse uitsluiting met streaming: UseAsyncInvoke en UseResponseStreaming kunnen niet beide op true staan voor dezelfde bestemming — ze vertegenwoordigen tegenovergestelde leveringsmodellen.

De functies combineren

Deze twee functies zijn onafhankelijk, maar ze combineren op natuurlijke wijze voor een specifiek patroon: een publiek WireGuard-endpoint dat een langlopende backend-workflow triggert.

Stel u een service voor voor het provisioneren van apparaten. Apparaten worden gefabriceerd zonder vooraf geregistreerde sleutels — ze genereren een sleutelpaar bij de eerste boot, maken verbinding met de open WireGuard Listener met behulp van de gedeelde PSK en sturen een pakket met een provisioneringsverzoek. Een Lambda-functie ontvangt het pakket, start een Step Functions state machine die de volledige provisioneringsworkflow afhandelt — identiteitsregistratie, uitgifte van certificaten, creatie van DynamoDB-records, SNS-notificaties — en keert terug. De state machine draait gedurende minuten of uren. Het apparaat ontvangt geen onmiddellijk antwoord; de bevestiging van de provisionering komt via een apart kanaal zodra de workflow is voltooid.

Niets hiervan vereist het beheren van een sleutelregister voordat apparaten worden verzonden. Niets hiervan vereist dat de Gateway een verbinding openhoudt voor de duur van de provisionering. Het is een pakket naar binnen, een gestarte workflow, en er draait geen infrastructuur tussen de events.

Hetzelfde patroon is van toepassing op elke inkomende getriggerde workflow waarbij de verzender geen onmiddellijk antwoord nodig heeft, zoals apparaatcommando's die een meerstapsvalidering starten vóór uitvoering, en audit-events die duurzame verwerkingsgaranties over meerdere systemen nodig hebben.

Aan de slag

Beide functies zijn nu beschikbaar in alle regio's waar UDP Gateway wordt ondersteund. Geen van beide vereist wijzigingen in bestaande Listeners of bestemmingen — AllowUnknownPeers staat standaard op false (waardoor het bestaande gedrag van de peer-lijst ongewijzigd blijft) en Lambda-bestemmingen blijven synchrone aanroeping gebruiken, tenzij UseAsyncInvoke expliciet is ingesteld.