Oracle Cloud (OCI) VCN Networking Guide - 夜莺博客

Oracle Cloud (OCI) VCN Networking Guide

OCI networking differs from the other clouds in one useful way: a Virtual Cloud Network is regional, and its subnets are regional too - each subnet exists in every availability domain of the region, with a security posture attached rather than a zone. That changes how you plan subnets, and it makes the gateway model the main thing to get right: internet gateway for public subnets, NAT gateway for private egress, service gateway for OCI services that should not traverse the internet, and dynamic routing gateway for anything leaving the VCN.

CIDR and Subnet Planning

  • One VCN per environment, sized /16 to start, so you never have to re-address running workloads.
  • Subnets are regional: name them by function (public-lb, private-app, private-db), not by availability domain.
  • Use separate subnets per tier and attach a network security group per tier; that gives you policy that survives address changes.
  • Reserve CIDR space for peering with on-premises and for a hub VCN before you create anything.

Gateways: The Four That Matter

  • Internet gateway - attaches to public subnets for inbound and outbound internet.
  • NAT gateway - outbound-only internet for private subnets. One per subnet is typical for availability.
  • Service gateway - private access to Object Storage and other OCI services without internet exposure. Free, and almost always worth adding.
  • Dynamic routing gateway (DRG) - the attachment point for FastConnect, Site-to-Site VPN and VCN-to-VCN traffic.
# OCI CLI: create the network building blocks
oci network vcn create --cidr-block 10.10.0.0/16 --display-name prod-vcn \
  --compartment-id $C --dns-label prodvcn

oci network subnet create --vcn-id $VCN --cidr-block 10.10.1.0/24 \
  --display-name public-lb --dns-label publb

oci network nat-gateway create --compartment-id $C --vcn-id $VCN \
  --display-name prod-nat

oci network service-gateway create --compartment-id $C --vcn-id $VCN \
  --display-name prod-svcgw \
  --services '["all-hz-services"]'

Then add route rules: 0.0.0.0/0 -> internet gateway on public subnets, 0.0.0.0/0 -> NAT gateway on private app subnets, and all-services -> service gateway for OCI API traffic.

Security Lists vs Network Security Groups

  • Security lists apply at the subnet level and are the legacy default; every instance in the subnet inherits them.
  • Network security groups (NSGs) apply to the VNICs you attach, and rules can reference another NSG as the source, which is how you express app-to-db policy without IP addresses.
  • Both are stateful. Rules that are not explicitly allowed are denied - there is no implicit permit inside a VCN.
oci network nsg create --compartment-id $C --vcn-id $VCN --display-name app-nsg
oci network nsg create --compartment-id $C --vcn-id $VCN --display-name db-nsg

oci network nsg rules add --nsg-id $APP_NSG --security-rules '[{
  "direction": "INGRESS",
  "protocol": "6",
  "sourceType": "NETWORK_SECURITY_GROUP",
  "source": "ocid1.networksecuritygroup.oc1..db",
  "tcpOptions": {"destinationPortRange": {"min": 3306, "max": 3306}}
}]'

Connecting VCNs and On-Premises

  • Local peering - same region, same tenancy. Simple and free.
  • Remote peering - across regions through DRGs in both regions.
  • Site-to-Site VPN - IPsec over the internet terminations on a DRG; fine for bandwidth-tolerant traffic with a backup path.
  • FastConnect - dedicated private connectivity with BGP; the equivalent of Direct Connect or ExpressRoute.
  • For hub-and-spoke topologies, OCI now supports a DRG as a hub with attachments, which removes the full-mesh peering problem.

Validation Checklist

  • Every private subnet has a NAT gateway route and no public IP on its instances.
  • Service gateway route present for Object Storage; confirm with a test that blocks internet egress.
  • Security policy expressed as NSG-to-NSG where possible, with IP-based rules only for external sources.
  • Flow logs enabled on the VCN for the subnets that matter, sent to Object Storage or Streaming.
  • Peering or FastConnect tested in both directions with a traceroute, not just a ping.

Compare the equivalent patterns in Azure VNet peering and gateway transit, AWS Transit Gateway route tables and ExpressRoute private peering with BGP.

原文链接:https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm