首先明确说：不用Azure VPN网关，直接让本地Fortigate和Azure Ubuntu VM建立站点到站点VPN是完全可行的，Azure并没有阻断这类配置，问题大概率出在网络配置或者StrongSwan的细节上。

你提到这套配置在其他服务商那里能正常跑，但Azure这边连Phase1都启动不了，而且Ubuntu VM没有外部IP，这可能是最核心的卡点——先给你梳理几个排查方向：

• 必须解决VM的公网访问问题：Azure的VM如果没有分配公共IP，外部是无法主动发起连接的，哪怕NSG开了端口也没用。其他服务商可能有不同的NAT策略，但Azure这里，要么给VM直接分配一个公共IP，要么通过NAT网关/负载均衡器做端口映射，确保Fortigate的公网IP能访问到VM的500/4500 UDP端口，这是协商的前提。
• 仔细校验NSG规则：你说已经开了500/4500 UDP的入站规则，建议再检查这几点：
  • 规则的优先级是不是高于其他拒绝类规则？Azure会按优先级执行规则，高优先级的拒绝会覆盖低优先级的允许。
  • 规则的源地址是不是设成了Fortigate的公网IP？测试阶段可以暂时设为0.0.0.0/0排除源地址限制的问题。
  • 同时检查VM所在子网的NSG和VM自身的NSG，确保没有冲突的规则。
• StrongSwan配置的细节调整：
  • left字段：如果VM现在没有公网IP，你填的xx是内部IP的话，Azure的SNAT会导致IKE协商时地址不匹配。建议先给VM分配公网IP，然后把left设为VM的公网IP，leftsourceip设为VM的内部IP（确保隧道流量用内部IP源）。
  • 确认right字段是Fortigate的公网IP，没有填错。
  • 利用你已经开启的charondebug = "all"，查看/var/log/syslog或者/var/log/strongswan.log里的日志，看看有没有收到Fortigate的IKE报文，或者协商过程中具体的错误（比如不匹配的加密算法、PSK错误、地址不可达等）。
• Fortigate侧的配置检查：虽然你说其他服务商能正常工作，但还是要确认Fortigate的IKEv2配置里，远程端点是不是指向Azure VM的公网IP（如果还没分配的话，这步肯定走不通），加密算法、PSK是不是和StrongSwan完全一致。

附上你提供的StrongSwan配置供参考：

ipsec.conf #

config setup
    charondebug = "all"
    uniqueids = yes

conn strongswan-to-fortigate
    type = tunnel
    auto = start
    keyexchange = ikev2
    authby = secret
    left = xx
    leftsubnet = 10.0.0.1/24
    right = yy
    rightsubnet = 192.168.1.1/24
    ike = aes256-sha256-modp2048
    esp = aes256-sha256
    aggressive = no
    keyingtries = %forever
    ikelifetime = 28800s
    lifetime = 3600s
    dpddelay = 20s
    dpdtimeout = 120s
    dpdaction = restart

ipsec.secret #

xx yy : PSK "key"

备注：内容来源于stack exchange，提问作者Zenon Brzęczyszczykiewicz