Назад | Перейти на главную страницу

Невозможно подключиться к рядовому серверу в сети vpn или наоборот, но почему?

Я создал тестовый VPC в AWS для проверки концепции OpenVPN.

В этом VPC я запустил рядовой сервер Linux и AMI сервера OpenVPN из AWS Marketplace, установил и настроил его.

Как клиент я могу подключиться к сети VPN и ssh на сервер OpenVPN, используя каждый из трех IP-адресов, но проблема в том, что я не могу ssh на рядовой сервер в основной подсети VPC.

Сеть между сервером OpenVPN и рядовым сервером полностью установлена.

Детали:

VPC CIDR: 172.16.0.0/16
VPC Main Subnet CIDR: 172.16.200.0/24 
VPN CIDR: 172.16.201.0/24

OVPN server: 
Main Subnet interface: 172.16.200.66
VPN Server interface: 172.16.201.1
VPN Client interface: 172.16.201.129

Member server:
Main Subnet interface: 172.16.200.71

My Client IP: 172.16.201.131-134 (disconnected a few times)

Я настроил сервер OpenVPN так: И:

Кроме того, я пробовал использовать NAT, но безуспешно.

Когда я бегу tcpdump с сервера OVPN при попытке ssh с клиентской машины на рядовой сервер:

openvpnas@openvpnas2:~$ sudo tcpdump -i as0t1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on as0t1, link-type RAW (Raw IP), capture size 262144 bytes
11:21:52.668974 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [SEW], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758529356 ecr 0,sackOK,eol], length 0
11:21:53.681875 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [S], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758530357 ecr 0,sackOK,eol], length 0

Я вижу, что сервер OVPN пытается переслать пакеты рядовому серверу, но во время работы tcpdump на интерфейсе рядового сервера я вижу, что пакеты не приходят.

Маршруты на сервере OVPN:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    0.0.0.0         255.255.255.128 U     0      0        0 as0t0
172.16.201.128  0.0.0.0         255.255.255.128 U     0      0        0 as0t1

Маршруты на рядовом сервере:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    172.16.200.66   255.255.255.0   UG    0      0        0 eth0

Маршруты на клиенте (мой ноутбук), некоторые из них добавлены мной вручную:

netstat -nr | grep tun
172.16.200/24      172.16.201.134     UGSc            4        4   utun2
172.16.201/24      172.16.200.66      UGSc            1        2   utun2
172.16.201.134     172.16.201.134     UH              3        4   utun2

Сетевые интерфейсы на сервере OVPN:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:fb:99:4a:67:04 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.66/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::fb:99ff:fe4a:6704/64 scope link
       valid_lft forever preferred_lft forever
3: pr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 36:ce:f1:ac:59:42 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::34ce:f1ff:feac:5942/64 scope link
       valid_lft forever preferred_lft forever
21: as0t0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.1/25 brd 172.16.201.127 scope global as0t0
       valid_lft forever preferred_lft forever
22: as0t1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.129/25 brd 172.16.201.255 scope global as0t1
       valid_lft forever preferred_lft forever

Сетевой интерфейс на рядовом сервере:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:c5:62:3b:ef:02 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.71/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c5:62ff:fe3b:ef02/64 scope link
       valid_lft forever preferred_lft forever

Еще несколько моментов:

ping от моего клиента к рядовому серверу:

$ ping 172.16.200.71
PING 172.16.200.71 (172.16.200.71): 56 data bytes
Request timeout for icmp_seq 0

ping от моего клиента к серверу OVPN (с использованием основной подсети VPC):

$ ping 172.16.200.66
PING 172.16.200.66 (172.16.200.66): 56 data bytes
64 bytes from 172.16.200.66: icmp_seq=0 ttl=64 time=87.657 ms

ping от моего клиента к OVPN vpn ip тоже работает.

Таблица маршрутизации этого VPC в AWS:

Вот мои вопросы:

  1. Должен ли я создать подсеть «172.16.201.0» (подсеть vpn) в VPC? (У меня есть, но это не решило проблему ... это всего лишь одна из вещей, которые я пробовал).

  2. Кажется, я чего-то упускаю, может быть, в конфигурации в AWS, можешь попробовать найти мою проблему?

Я могу придумать 3 вещи, на которые вы можете взглянуть

  1. В настоящее время все, что находится в диапазоне CIDR 172.16.0.0/16, будет маршрутизироваться, хотя по локальному маршруту все остальное 0.0.0.0/0 будет отправлено через интернет-шлюз. поскольку ваша подсеть VPN попадает в диапазон 172.16.0.0/16, это может вызвать проблемы. может быть:

а. выберите другой диапазон адресов для вашей подсети VPN

б. убедитесь, что в таблице маршрутов есть маршрут, который направляет трафик в эту подсеть через VPN-устройство

  1. Вы видели группы безопасности, связанные с вашими инстансами EC2? разрешают ли они правильный трафик (в данном случае SSH), который вы хотите передать в тот экземпляр EC2
  2. Просматривали ли вы сетевые ACL, связанные с вашим VPC и его подсетями, разрешают ли они правильный трафик как входящий, так и исходящий?