Jak skonfigurować niestandardowy NAT do użytku w Amazon VPC

Mam pole Ubuntu, którego chcę używać jako instancji NAT (między innymi). Wolałbym unikać używania NAT AMI dostarczonych przez Amazon, zamiast samemu konfigurować NAT.

Obecnie mój host ma jeden interfejs sieciowy (jak pokazano w http://docs.amazonwebservices.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html ).

Czy powinienem być w stanie skonfigurować mojego hosta Ubuntu jako instancję NAT dla innych hostów w mojej sieci Amazon?

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  

Próbowałem skonfigurować regułę NAT na hoście Ubuntu (10.200.0.51). Mój drugi host jest w innej sieci (10.200.10.41/24). Więc napisałem:

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

Ale urządzenie straciło połączenie.

Co nieporozumienie przestawiam na używanie instancji NAT i routingu w Amazon?

Możesz sprawdzić skrypt Amazon, aby skonfigurować NAT na komputerze z systemem Linux, jest on dostarczany z domyślnym AMI ami-vpc-nat, w /usr/local/sbin/configure-pat.sh

To wygląda tak:

#!/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

Zainstalowałem Amazon NAT AMI i sprawdziłem odpowiednią konfigurację:

[root @ ip-10-200-0-172 ec2-user] # iptables -L -n -v -x -t nat
PREZENTACJA łańcucha (polityka AKCEPTUJE 11 pakietów, 660 bajtów)
    pkts bajty target prot opt ​​w źródłowym miejscu docelowym         

Chain INPUT (polityka ACCEPT 11 pakietów, 660 bajtów)
    pkts bajty target prot opt ​​w źródłowym miejscu docelowym         

Chain OUTPUT (polityka ACCEPT 357 pakietów, 24057 bajtów)
    pkts bajty target prot opt ​​w źródłowym miejscu docelowym         

Łańcuch POSTROUTING (polityka AKCEPTUJE 0 pakietów, 0 bajtów)
    pkts bajty target prot opt ​​w źródłowym miejscu docelowym         
     357 24057 MASQUERADE wszystkie - * eth0 10.200.0.0/16 0.0.0.0/0

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

Ponadto maszyna musi mieć publiczny adres IP, a kontrola Sourc / Dest musi być wyłączona.

Ten komputer może być następnie użyty jako instancja NAT.

Trasowanie dla innych hostów jest konfigurowane na poziomie EC2 (przy użyciu funkcji „Tabela routingu”).

Jest kilka instrukcji, które mi pomogły.

Uwagi:

• 10.0.0.23 - prywatny adres IP instancji, który postanowiłem zrobić jako „inst-nat”, to wystąpienie z EIP.
• 10.0.0.0/24 - podsieć VPN

W „nat-instance” jako użytkownik root:

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

po tym:

[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 

poprzez konsolę AWS:

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

W innych przypadkach bez EIP:

sudo route add default gw 10.0.0.23

UPD : Dowiedziałem się, że każde nowe wystąpienie w moim VPC poprawnie wykrywało internet po pingowaniu domyślnego gw.

Więc:

[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

Wiem, że to nie jest problem, ale może zaoszczędzić trochę czasu