Amazon VPC'de kullanmak için özel bir NAT nasıl yapılandırılır

NAT (başka şeylerin yanı sıra) olarak kullanmak istediğim bir Ubuntu kutusu var. Amazon tarafından sağlanan NAT AMI'leri kullanmaktan ve bunun yerine NAT'ı kendim yapılandırmaktan kaçınmayı tercih ederim.

Şu anda sunucumun tek bir ağ arayüzü var ( http://docs.amazonwebservices.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html sayfasında gösterildiği gibi ).

Ubuntu ana makinemi Amazon ağımdaki diğer ana bilgisayarlar için NAT örneği olarak yapılandırabilir miyim?

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       5      454 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0  

Ubuntu ana bilgisayarında (10.200.0.51) bir NAT kuralı yapılandırmayı denedim. İkinci sunucum farklı bir ağda (10.200.10.41/24). Ben de yazdım:

route add -net 10.200.0.0 netmask 255.255.255.0 dev eth0 # So I can reach 10.200.0.51
route add default gw 10.200.0.51

Ancak makine bağlantıyı kesti.

Amazon'da NAT örneklerinin kullanımından ve yönlendirmesinden kaynaklanan yanlış anlama nedir?

Bir Linux makinesinde NAT'ı yapılandırmak için Amazon'un komut dosyasını kontrol edebilirsiniz, varsayılan ami-vpc-nat AMI ile birlikte gelir. /usr/local/sbin/configure-pat.sh

Şöyle görünüyor:

#!/bin/bash
# Configure the instance to run as a Port Address Translator (PAT) to provide 
# Internet connectivity to private instances. 

function log { logger -t "vpc" -- $1; }

function die {
    [ -n "$1" ] && log "$1"
    log "Configuration of PAT failed!"
    exit 1
}

# Sanitize PATH
PATH="/usr/sbin:/sbin:/usr/bin:/bin"

log "Determining the MAC address on eth0..."
ETH0_MAC=$(cat /sys/class/net/eth0/address) ||
    die "Unable to determine MAC address on eth0."
log "Found MAC ${ETH0_MAC} for eth0."

VPC_CIDR_URI="http://169.254.169.254/latest/meta-data/network/interfaces/macs/${ETH0_MAC}/vpc-ipv4-cidr-block"
log "Metadata location for vpc ipv4 range: ${VPC_CIDR_URI}"

VPC_CIDR_RANGE=$(curl --retry 3 --silent --fail ${VPC_CIDR_URI})
if [ $? -ne 0 ]; then
   log "Unable to retrive VPC CIDR range from meta-data, using 0.0.0.0/0 instead. PAT may be insecure!"
   VPC_CIDR_RANGE="0.0.0.0/0"
else
   log "Retrieved VPC CIDR range ${VPC_CIDR_RANGE} from meta-data."
fi

log "Enabling PAT..."
sysctl -q -w net.ipv4.ip_forward=1 net.ipv4.conf.eth0.send_redirects=0 && (
   iptables -t nat -C POSTROUTING -o eth0 -s ${VPC_CIDR_RANGE} -j MASQUERADE 2> /dev/null ||
   iptables -t nat -A POSTROUTING -o eth0 -s ${VPC_CIDR_RANGE} -j MASQUERADE ) ||
       die

sysctl net.ipv4.ip_forward net.ipv4.conf.eth0.send_redirects | log
iptables -n -t nat -L POSTROUTING | log

log "Configuration of PAT complete."
exit 0

Bir Amazon NAT AMI yükledim ve ilgili yapılandırmayı kontrol ettim:

[root @ ip-10-200-0-172 ec2-kullanıcı] # iptables -L -n -v -x -t nat
Zincir PREROUTING (politika KABUL 11 paket, 660 bayt)
    pkts bayt hedefi koruma seçimi dışarı çıkış hedef         

Zincir GİRİŞİ (politika KABUL 11 paket, 660 bayt)
    pkts bayt hedefi koruma seçimi dışarı çıkış hedef         

Zincir ÇIKIŞI (politika ACCEPT 357 paketleri, 24057 bayt)
    pkts bayt hedefi koruma seçimi dışarı çıkış hedef         

Zincir POSTROUTING (politika KABUL 0 paket, 0 bayt)
    pkts bayt hedefi koruma seçimi dışarı çıkış hedef         
     357 24057 MASQUERADE tümü - * eth0 10.200.0.0/16 0.0.0.0/0

[root @ ip-10-200-0-172 ec2-kullanıcı] # cat / proc / sys / net / ipv4 / ip_forward 
1

Ayrıca, makinenin genel bir IP'ye sahip olması ve Sourc / Dest kontrolünün devre dışı bırakılması gerekir.

Bu makine daha sonra NAT örneği olarak kullanılabilir.

Diğer ana makineler için yönlendirme EC2 düzeyinde yapılandırılır ("Yönlendirme tablosu" özelliği kullanılarak).

Bana yardımcı olan birkaç talimat var.

Notlar:

• 10.0.0.23 - özel IP örneği, "nat-instance" olarak yapmaya karar verdim, bu örnek EIP ile.
• 10.0.0.0/24 - vpc alt ağı

"Nat-instance" da kök kullanıcı olarak:

sysctl -q -w net.ipv4.ip_forward=1 net.ipv4.conf.eth0.send_redirects=0
iptables -t nat -C POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE 2> /dev/null || iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

bundan sonra:

[sysctl file]
net.ipv4.ip_forward = 1
net.ipv4.conf.eth0.send_redirects = 0

[iptables]
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.0.0.0/24          0.0.0.0/0 

AWS Konsolu ile:

Grant all traffic from 10.0.0.0/24 (into security groups)
Set disabled source/dest. check (right click on "nat" instance)

EIP'siz diğer durumlarda:

sudo route add default gw 10.0.0.23

UPD : VPC'mdeki her yeni örneğin varsayılan gw'ye ping attıktan sonra İnternet'i doğru algıladığını öğrendim.

Yani:

[ec2-user@ip-10-0-0-6 ~]$ ping google.com
PING google.com (173.194.33.71) 56(84) bytes of data.
^C
--- google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2356ms

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.23
PING 10.0.0.230 (10.0.0.23) 56(84) bytes of data.
64 bytes from 10.0.0.23: icmp_seq=1 ttl=64 time=1.22 ms
64 bytes from 10.0.0.23: icmp_seq=2 ttl=64 time=0.539 ms
64 bytes from 10.0.0.23: icmp_seq=3 ttl=64 time=0.539 ms
^C
--- 10.0.0.23 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2500ms
rtt min/avg/max/mdev = 0.539/0.768/1.228/0.326 ms
[ec2-user@ip-10-0-0-6 ~]$ ping google.com
PING google.com (173.194.33.70) 56(84) bytes of data.
64 bytes from sea09s15-in-f6.1e100.net (173.194.33.70): icmp_seq=1 ttl=55 time=13.5 ms
64 bytes from sea09s15-in-f6.1e100.net (173.194.33.70): icmp_seq=2 ttl=55 time=14.2 ms

Biliyorum, bu bir sorun değil, ama biraz zaman kazandırabilir