Я настроил свой сервер (server1) для подключения к другому серверу (server2) через VPN с IPsec (безопасный vpn). Но теперь мне нужно настроить другой VPN (рабочий vpn), чтобы я мог подключиться к моему серверу (server1) и получить доступ к другому серверу (server2).
У моего сервера 1 внешний сетевой интерфейс (eth0 с IP 71.185.153.102 - доступ в Интернет). Безопасный VPN использует eth0: 0, который представляет собой виртуальный сетевой интерфейс с IP 71.185.200.240.
Цель: подключиться к защищенному VPN (из моего рабочего офиса) и получить доступ к странице на нем с адресом: http://20.35.166.61:6084/test/
Как это должно работать:
мой домашний офис -> подключается к рабочему VPN (который находится на моем сервере) -> сервер получает пакеты через интерфейс ppp0 -> iptables должен пересылать и переводить все пакеты в eth0: 0 (VPN через IPsec)
Что я сделал до сих пор:
Но проблема в том, что ничего не работает, и я не совсем уверен, как отладить его, чтобы увидеть, что идет не так (не эксперт по сетям). Я могу подключиться через VPN, но через пару минут он отключается. И я не могу пинговать IP-адрес в защищенной VPN (я могу пинговать его с сервера). Также, когда я подключаюсь к VPN, мое интернет-соединение разрывается.
Я также готов сделать это любым другим способом, если у меня есть доступ к веб-странице.
Диаграмма сети: Диаграмма сети
У вас действительно есть два возможных пути сюда.
Избавьтесь от всего, что связано с PPtP VPN, и вместо этого используйте SSH-туннель. Предполагая, что вы можете подключиться к своей машине по SSH, вам не нужно будет ничего настраивать или выполнять какую-либо реконфигурацию, которая может что-либо сломать.
Вы не указали, какую операционную систему вы используете на своем клиенте, но я предполагаю, что вы используете либо PuTTY в Windows, либо OpenSSH в какой-либо другой ОС (Mac OS X, Linux и т. Д.).
В PuTTY в Windows вы должны перейти в SSH-> Tunnels и добавить перенаправленный порт, например source = 6084, destination = 20.35.166.61:6084, а затем подключиться к серверу. (Полезно сохранить профиль, чтобы не настраивать его каждый раз.)
С OpenSSH вы бы что-то вроде ssh -L 6084:20.35.166.61:6084 yourusername@71.185.153.102
(yourusername @ может быть опущено, если оно совпадает с вашим локальным именем пользователя на вашем компьютере).
Затем вы сможете получить доступ к удаленному веб-серверу, используя http://127.0.0.1:6084. Некоторым веб-приложениям не понравится использование другого IP-адреса, и они будут ломать ссылки. В некоторых случаях будет достаточно добавить имя хоста защищенного сервера в ваш файл hosts (C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS
в Windows, /etc/hosts
в OS X, Linux и других подобных ОС) - с IP-адресом 127.0.0.1. Это, конечно, сломает ситуацию, если вы попытаетесь сделать что-нибудь еще, кроме подключения к порту 6084 на этом конкретном имени хоста, или если сеанс ssh не запущен.
Альтернативой туннелированию одного порта является использование «динамического туннелирования SSH», что означает, что клиент ssh имитирует прокси-сервер SOCKS. В этом режиме вы бы сделали что-то вроде ssh -D 3128 yourusername@71.185.153.102
(с OpenSSH) или, используя PuTTY, выбирая «динамический» туннель с 3128 в качестве исходного порта (вам не нужно указывать место назначения). Затем вы настраиваете свой веб-браузер с помощью 127.0.0.1:3128
в качестве прокси-сервера SOCKS, и бац - весь трафик вашего веб-браузера будет перенаправляться через ваш сервер. Это включает в себя любой другой веб-трафик с вашего компьютера, поэтому будьте осторожны, если это не то, что вам нужно. Кроме того, это означает, что ваш веб-браузер перестанет работать, когда ваш SSH-туннель отключится.
Вы, кажется, перечислили несколько конкретных проблем.
Вероятно, это из-за брандмауэра с проверкой пакетов с отслеживанием состояния (например, «широкополосный маршрутизатор» в вашем саду) где-то между вами и сервером, вызывая тайм-аут соединения. В зависимости от производителя и модели этого межсетевого экрана вы можете увеличить время ожидания. В качестве обходного пути вы можете установить set link keep-alive
в PoPToP на что-то достаточно низкое, чтобы сеансы не истекли.
Это связано с тем, что при подключении к вашей VPN ваш «маршрут по умолчанию» будет настроен на прохождение через VPN-соединение. Т.е. он попытается отправить ваш интернет-трафик через ваш сервер. Если вы не настроили исходный NAT, трафик, который выходит с сервера в большую часть Интернета, будет иметь IP-адрес между 192.168.0.100-200 в качестве исходного IP-адреса, и хотя ваши пакеты могут попасть в пункт назначения, у вас нет возможности узнать, потому что удаленный хост не имеет возможности отправить ваш трафик обратно на ваш немаршрутизируемый IP-адрес.
Есть несколько возможных решений этой проблемы:
Это не работает по той же причине, по которой перестает работать ваше Интернет-соединение - пакеты вполне могут достигать места назначения, но удаленный сервер не может отправить пакеты обратно вам.
Возможные решения: