AWS Lambda自定义VPC跨VPC调用HTTPS WebService失败问题排查求助

First off, let's tackle the immediate error in your code—right now, you're not handling errors from soap.createClient, which is why you're seeing that Cannot read property 'GetLocationData' of undefined message. If the client creation fails (due to network/certificate issues), client will be undefined, so you need to add error checking there first:

soap.createClient(aUrl, options, function(err, client) {
  if (err) {
    console.error('Failed to initialize SOAP client for aUrl:', err);
    return callback(err); // Or handle the error appropriately
  }
  var method = client['GetLocationData'];
  // Rest of your code...
});

Now let's answer your three core questions:

1. Which Lambda configuration items need checking? #

Since your EC2 in the same subnet can reach the service but Lambda can't, focus on Lambda-specific VPC and security settings:

• Lambda Security Group Outbound Rules: Ensure the security group attached to your Lambda allows outbound HTTPS (port 443) traffic to the target VPC's load balancer IP range or the WebService's domain. EC2's security group might have this rule, but Lambda's might not.
• VPC Subnet Routing: Verify the subnet your Lambda is deployed in has a route to the target VPC (via VPC peering, transit gateway, or other connectivity). Even if EC2 works, double-check the route table—Lambda uses ENIs in the subnet, so routing must be identical for both.
• Lambda VPC ENI Configuration: Confirm Lambda has successfully created an Elastic Network Interface (ENI) in your subnet. If the ENI creation failed (e.g., insufficient IPs in the subnet), Lambda can't send network traffic.
• Target Load Balancer Security Group Inbound Rules: Make sure the LB's security group allows inbound HTTPS traffic from Lambda's security group (or the subnet's CIDR range). Your EC2's IP is allowed, but Lambda's ENI IPs might be blocked.
• Environment Variables: Double-check that a_url and b_url are correctly set in Lambda's environment variables—typos here would cause failed connections even if network settings are correct.

2. How does Lambda handle HTTPS certificates? #

Lambda runs on AWS-managed environments that trust public CA-issued certificates by default (like Let's Encrypt, AWS Certificate Manager, or major commercial CAs). However:

• If your target WebService uses a private CA-issued certificate, Lambda won't trust it out of the box. You'll need to bundle the private CA certificate with your Lambda deployment package and configure the SOAP client to use it. For strong-soap, add the certificate to your options object:

  const fs = require('fs');
  const caCert = fs.readFileSync('./private-ca-cert.pem');
  var options = {
    sslOptions: {
      ca: caCert
    }
  };
  

• Certificate validation failures (like expired certs, mismatched domains) will cause the TLS handshake to fail, leading to socket errors exactly like the one in your logs.

3. Are there tracert-like tools for troubleshooting blocked calls? #

You can't run tracert or traceroute directly in Lambda, but here are effective alternatives:

• VPC Flow Logs: Enable flow logs on your Lambda's subnet or ENI. This will show you if traffic from Lambda's ENI is being sent to the target LB, if it's being rejected, or if it's not leaving the subnet at all. Look for entries with destination port 443 to the LB's IP.
• DNS Resolution Test: Add a quick DNS lookup in your code to confirm Lambda can resolve the target domain:

  const dns = require('dns');
  dns.lookup('first.second.example.com', (err, address) => {
    if (err) console.error('DNS lookup failed:', err);
    else console.log('Resolved domain to:', address);
  });
  

• TCP Connection Test: Use Node.js's net module to test basic connectivity to the target port:

  const net = require('net');
  const socket = net.createConnection(443, 'first.second.example.com');
  socket.on('connect', () => {
    console.log('Successfully connected to port 443');
    socket.end();
  });
  socket.on('error', (err) => console.error('Connection failed:', err));
  

• Verbose Curl Output: If your Lambda uses Amazon Linux 2 (most recent runtimes), you can execute curl with verbose output to see the TLS handshake and connection steps:

  const { exec } = require('child_process');
  exec('curl -v ' + aUrl, (err, stdout, stderr) => {
    console.log('Curl stdout:', stdout);
    console.error('Curl stderr/debug:', stderr);
  });
  

内容的提问来源于stack exchange，提问作者CharlesDeeZee