У меня есть пара серверов в Линоде. Я пытаюсь настроить их так, чтобы у меня была VPN на одной из машин, а затем я мог получить доступ ко всем другим машинам, используя частную сеть linode. В этом случае общий доступ к частным службам (SSH и т. Д.) Будет ограничен только теми, у кого есть доступ к VPN.
Примечание: у меня есть нет брандмауэров работает на этих серверах еще.
root@internal:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
внутренний сервер (под управлением openvpn server)
eth0 Link encap:Ethernet HWaddr f2:3c:91:db:68:b4
inet addr:23.239.17.12 Bcast:23.239.17.255 Mask:255.255.255.0
inet6 addr: 2600:3c02::f03c:91ff:fedb:68b4/64 Scope:Global
inet6 addr: fe80::f03c:91ff:fedb:68b4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:80780 errors:0 dropped:0 overruns:0 frame:0
TX packets:102812 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14317079 (14.3 MB) TX bytes:17385151 (17.3 MB)
eth0:1 Link encap:Ethernet HWaddr f2:3c:91:db:68:b4
inet addr:192.168.137.64 Bcast:192.168.255.255 Mask:255.255.128.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.20.1.1 P-t-P:172.20.1.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:2318 errors:0 dropped:0 overruns:0 frame:0
TX packets:1484 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:174573 (174.5 KB) TX bytes:170941 (170.9 KB)
Комментарии к вышеизложенному:
сервер базы данных (nix03):
root@nix03:~# ifconfig eth0 Link encap:Ethernet HWaddr f2:3c:91:73:d2:cc
inet addr:173.230.140.52 Bcast:173.230.140.255 Mask:255.255.255.0
inet6 addr: 2600:3c02::f03c:91ff:fe73:d2cc/64 Scope:Global
inet6 addr: fe80::f03c:91ff:fe73:d2cc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12348 errors:0 dropped:0 overruns:0 frame:0
TX packets:44434 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1166666 (1.1 MB) TX bytes:5339936 (5.3 MB)
eth0:1 Link encap:Ethernet HWaddr f2:3c:91:73:d2:cc
inet addr:192.168.137.63 Bcast:192.168.255.255 Mask:255.255.128.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Комментарии к вышеизложенному:
Текущая проблема
Я хочу иметь возможность подключаться к серверу базы данных через VPN. С моего VPN-клиента (ноутбук в моем офисе) я хотел бы иметь возможность пинговать 192.168.137.63. Однако в настоящее время это не удается.
В своих попытках устранить неполадки я решил подойти к нему со стороны сервера db и посмотреть, смогу ли я пропинговать VPN-туннель на внутреннем сервере (172.20.1.1). Я понял, что мне нужно будет настроить маршрут на сервере базы данных, чтобы сообщить ему, куда отправлять пакеты, предназначенные для сети 172.20.1.0/24, поэтому я сделал это:
root@nix03:~# ip route add 172.20.1.0/24 via 192.168.137.64 root@nix03:~# ip route list default via 173.230.140.1 dev eth0
172.20.1.0/24 via 192.168.137.64 dev eth0
173.230.140.0/24 dev eth0 proto kernel scope link src 173.230.140.52
192.168.128.0/17 dev eth0 proto kernel scope link src 192.168.137.63 root@nix03:~# ip route get 172.20.1.1
172.20.1.1 via 192.168.137.64 dev eth0 src 192.168.137.63
cache
Так, думаю исходя из вышеизложенного, когда я пингую 172.20.1.1, мой сервер должен отправлять пакеты на 192.168.137.64 (внутренний сервер). Этот сервер должен, из-за переадресации ip, взять пакет от eth0: 1 и направить его на tun0 (172.20.1.1).
Но, как вы могли догадаться, пинг 172.20.1.1 с nix03 (db server) не работает.
Я сделал несколько захватов пакетов, чтобы увидеть, на какой MAC-адрес отправлялись мои ICMP-пакеты:
root @ nix03: ~ # tcpdump -i eth0 -e icmp tcpdump: подробный вывод подавлен, используйте -v или -vv для прослушивания полного декодирования протокола на eth0, тип канала EN10MB (Ethernet), размер захвата 65535 байт 16: 41: 39.623759 f2: 3c: 91: 73: d2: cc (oui Unknown)> f2: 3c: 91: db: 68: b4 (oui Unknown), ethertype IPv4 (0x0800), длина 98: 192.168.137.63> 172.20.1.1: ICMP эхо-запрос, id 3324, seq 33653, длина 64 root @ nix03: ~ # arp Address HWtype HWaddress Flags Mask Iface 192.168.137.64 ether f2: 3c: 91: db: 68: b4 C eth0
И это говорит мне, что пакеты должны попасть на внутренний сервер. По крайней мере, их отправляют на правильный сетевой адаптер. Однако, когда я запускаю tcpdump на eth0 и eth0: 1 внутреннего сервера, я не вижу никаких пакетов icmp, поступающих с сервера db.
Что еще можно попробовать? Заранее спасибо.
Обновление # 1
Таблица маршрутизации для «внутреннего» сервера:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gw-li686.linode 0.0.0.0 UG 0 0 0 eth0
23.239.17.0 * 255.255.255.0 U 0 0 0 eth0
172.20.1.0 172.20.1.2 255.255.255.0 UG 0 0 0 tun0
172.20.1.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.128.0 * 255.255.128.0 U 0 0 0 eth0
В итоге мне пришлось добавить правило NAT на внутренний сервер. Я не уверен, что это необходимо, но это то, что сработало:
*nat
:PREROUTING ACCEPT [21:1248]
:INPUT ACCEPT [21:1248]
:OUTPUT ACCEPT [21:1529]
:POSTROUTING ACCEPT [21:1529]
# enable NAT for VPN clients so they can hit the private network
-A POSTROUTING -s 172.20.1.0/24 -o eth0 -j MASQUERADE
COMMIT
Я столкнулся с той же проблемой и пришел к выводу, что Linode не очень подходит для такой конфигурации VPN.
Прежде всего: то, что вы пытались сделать (настроить маршрут) от 192.168.137.63 (eth0: 1 на nix03) до 172.20.1.1 (tun0 на внутреннем), действительно правильно и работает в настройках без Linode. Я описал такая же настройка на форумах Linode и Я получил ответ от бывшего сотрудника Linode, который сообщил мне, что Linode запрещает подобные установки..
Более того, даже если преобразование VPN-трафика во внутреннюю сеть, как вы, действительно является еще одним правильным подходом, имейте в виду, что подсеть 192.168.128.0/24 является частной не для вас, а для всех клиентов Linode с виртуальными машинами в том же центре обработки данных, что и вы. . Попробуйте nmap, чтобы проверить, что я говорю:
nmap -sP 192.168.128.0/17
Итак, в случае с Линодом, если вы действительно хотите:
В этом случае общий доступ к частным службам (SSH и т. Д.) Будет ограничен только теми, у кого есть доступ к VPN.
вам необходимо тщательно настроить брандмауэр, чтобы разрешить доступ только к точным IP-адресам, поскольку подсеть является частной только в ЦОД Linode клиенты значение слов.