Попытка подключиться к серверам в удаленной локальной сети с помощью softtether vpn client и iptables nat ip_forwarding

Хорошо, так что продолжаем https://superuser.com/questions/923747/vpn-ip-forwarding-and-nat/925570#925570 У меня может быть действительно глупый вопрос, но если все, что вам нужно, это доступ к определенным портам, например http / https, пробовали ли вы туннелирование SSH? Это намного проще, чем настроить VPN. В конечном итоге вы отправляете ssh с одной машины на другую, а затем целевая машина устанавливает прямое соединение с чем-то, и это соединение перенаправляется обратно на вашу локальную машину.

Допустим, вы можете получить доступ к общедоступной (DMZ) части машины AAAA, которая, в свою очередь, может получить доступ к частной машине BBBB, и вы хотите подключиться к службе HTTPS (порт 443), и при условии, что на вашем рабочем столе уже есть служба, работающая на 443 , так что вы собираетесь прослушивать службу локально на 4443.

   ssh -L4443:B.B.B.B:443 adminuser@A.A.A.A

Затем войдите в систему, запустите локальный браузер и перейдите в https: // локальный: 4443 или, если хотите, добавьте запись в файл хостов, отправив 127.0.0.1 на назначенный.vhost.name, а затем перейдите к https://intended.vhost.name:4443/

Если вам ДЕЙСТВИТЕЛЬНО нужен vpn, то ...

Можете ли вы пропинговать IP-адрес как локальной, так и противоположной сторон туннеля со своего ноутбука? Можете ли вы пропинговать другой компьютер в сети противоположного сайта? Если вы не можете попробовать трассировку, и посмотрите, получаете ли вы эхо от локального и удаленного сайтов туннеля (если нет, ваша маршрутизация неверна).

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

Я перечитывал это и подумал, что добавлю несколько примечаний, которые могут облегчить любому, кто пытается следовать тому, что я предложил:

Чтобы сделать возможным доступ https://intended.vhost.name:4443/ и у вас есть этот туннель, вам нужно добавить запись в файл hosts. В Linux это / etc / hosts в Windows c: / windows / system32 / drivers / etc / hosts В любом случае вам потребуются права администратора для сохранения файла (sudo для Linux, откройте блокнот от имени администратора в Windows). Затем добавьте следующую строку: -

127.0.0.1        intended.vhost.name

Еще я упомянул о настройке прослушивающего туннеля на машине, который может пробить брандмауэр. Как обсуждалось ранее, запуск ssh -L4443: BBBB: 443 adminuser @ AAAA откроет терминал ssh на машине AAAA, и при этом будет туннелировать трафик с локального (-L) порта 127.0.0.1:4443 на BBBB: 443 ( 127.0.0.1). Предполагая, что ваш локальный компьютер - C.C.C.C, и вы хотите открыть порт 4443 на этом IP-адресе, для доступа других машин вы можете сделать это: -

ssh -LC.C.C.C:4443:B.B.B.B:443 adminuser@A.A.A.A

Здесь стоит отметить, что если вы добавите параметр -T, вы измените поведение ssh, чтобы открыть ssl-соединение, а затем туннель, а не запускать терминал в нем.

Когда я делал это раньше, я настраиваю пользователя на локальном компьютере (скажем, tunneluser) и создаю для него набор ключей ssh ​​в ~ tunneluser / .ssh, затем проверяю, что файл ~ tunneluser / .ssh / id_rsa.pub перечисленные на удаленных машинах ~ adminuser / .ssh / authorized_keys, то соединение ssh будет запускаться без запроса пароля. В качестве функции безопасности вы можете настроить туннель-пользователя удаленно, используя / bin / false в качестве его оболочки (в / etc / passwd), тогда соединение не удастся, если вы пропустите параметр -T.

Самый простой способ реализовать это - включить его в сценарий в /etc/init.d, который запускается после подключения к сети (обычно в rc3.d). Я бы предложил уровень безопасности (не запускайте его как root), используя

sudo -u tunneluser "ssh -T -i/home/tunneluser/.ssh/id_rsa.pub -LC.C.C.C:4443:B.B.B.B:443 tunneluser@A.A.A.A"

Однако обратите внимание, что если IP-адрес, который вы хотите прослушивать (указанный выше: 4443), является «привилегированным портом» (т.е. он входит в диапазон, обычно используемый системными службами), вам необходимо запустить ssh как root, чтобы получить разрешение слушать там.

Тогда любому пользователю окна потребуется просто доступ https: //C.C.C.C: 4443 и они увидят сайт, который был на https: //B.B.B.B: 443.

Если машина в C.C.C.C не имеет блокировки службы: 443, используйте ее вместо: 4443 и https: //C.C.C.C будет эквивалентно https: //B.B.B.B

В стороне, если намерение обратное, скажем, вы находитесь на машине с доступом кCCC, вы хотите пробить дыру через DMZ через машину AAAA, чтобы пользователи, которые могут получить доступ к BBBB, могли получить доступ кCCC через туннель, не имея возможности чтобы получить к нему прямой доступ, вы используете -R вместо -L (и прослушивающий сокет находится на удаленной, а не локальной стороне туннеля). Я добавляю -T, чтобы показать, как он используется.

ssh -T -RB.B.B.B:4443:C.C.C.C:443 adminuser@A.A.A.A

Нет никакой разницы в маршрутизации, необходимой для ssh и http. Оба работают по TCP и не играют с базовым IP-трафиком.

Согласно вашему вопросу, оба используют одно и то же имя хоста, но вы не указали, разрешается ли это имя хоста только на один или несколько IP-адресов. Используя telnet вы можете проверить, можно ли установить соединение как с портом 22, так и с портом 80 на сервере. По пути он также сообщит вам, к какому IP-адресу он подключается.

Из вопроса я вижу, что вы используете свои ssh и http-серверы на том же имени хоста, что и ваш VPN-сервер. Это могло быть проблемой. Настоящая проблема здесь не столько в том, что они используют одно и то же имя хоста, сколько в том, что они используют один и тот же IP-адрес. Даже если вы использовали разные имена хостов, указывающие на один и тот же IP-адрес, это все равно могло быть проблемой, но тогда разные имена хостов скрывали бы источник проблемы.

Причина, по которой может возникнуть проблема с подключением к службе на том же IP-адресе, что и VPN-сервер, связана с маршрутизацией. Проблема заключается в том, что если запись в таблице маршрутизации, направляющая трафик через VPN, также охватывает IP-адрес сервера VPN, то пакеты на сервер VPN отправляются не по сети, а в интерфейс VPN. Это приведет к возникновению цикла маршрутизации, в котором каждый раз, когда пакет проходит по циклу, он еще раз зашифровывается и становится немного больше, но не приближается к месту назначения.

Одно из решений, которое используют некоторые решения VPN, чтобы избежать этого, заключается в том, что запись в таблице маршрутизации, охватывающая только IP-адрес VPN-сервера, создается до внесения любых других изменений. Таким образом, трафик к серверу VPN никогда не будет проходить через VPN. Но трафик к любым другим службам, размещенным на том же IP, также никогда не будет проходить через VPN.

Самое простое решение - использовать два разных IP-адреса для доступа к VPN и другим службам, размещенным в одном устройстве. Обычно VPN-серверу назначается достаточно IP-адресов, поэтому есть еще один IP-адрес, который можно использовать для этой цели.

Так почему это работает для ssh, а не для http? Информация в вашем вопросе указывает на одну возможную причину.

Вы упомянули, что хотите ограничить доступ к службе http только для пользователей, подключающихся с IP-адреса VPN. Если у вас уже есть эти фильтры, возможно, причина в этом. Соединение просто не проходит через VPN-соединение и поэтому блокируется фильтрами. Причина, по которой он будет работать при использовании ssh, а не http, может заключаться в том, что sshd настроен на разрешение подключений с любого IP-адреса, а не только из диапазона VPN.

Другое возможное объяснение заключается в том, что службы ssh и http не привязаны к одному и тому же IP-адресу. Возможно, ssh привязан к любому адресу, а http привязан только к одному конкретному адресу.

Эти две причины ни в коем случае не являются полным списком возможных объяснений, а просто теми, которые наиболее вероятны с учетом информации в вашем вопросе.