Тот же IP во многих системах в различных средах
Предоставление доступа через RDC не безопасно, по-моему. Пользователи могли бы посмотреть на другие частные данные, которые Вы могли бы иметь также. Также это довольно медленно, и Дистанционная работа берет много пропускной способности, и пользователи могли бы видеть много задержек в их конце.
Веб-приложение дает Вам большой контроль, Вы могли установить пользовательские уровни и предоставить отдельные логины каждому пользователю без доплаты. Это - инвестиции времени + стоимость текущего технического обслуживания все же.
Вы упомянули, что используете VPN для каждого сайта. Может ли каждый сайт иметь DNS-сервер (или два) с собственным доменом сайта (site1.mycorp.com, site2.mycorp.com) и использовать что-то вроде Bind views ( http://www.zytrax.com/ books / dns / ch7 / view.html ) для предоставления IP-адресов именованным хостам в сети VPN?
Таким образом, вы можете дать каждому хосту на каждом сайте уникальное полное доменное имя ( barney.site1.mycorp .com и rubble.site2.mycorp.com ), и эти узлы будут разрешаться правильно только в том случае, если вы подключены к правильному сайту через VPN и откликнетесь на представление привязки. На каждом сайте barney.site1.mycorp.com и rubble.site2.mycorp.com потенциально могут иметь один и тот же IP-адрес. Но они не разрешились бы извне или если бы вы были подключены не к той VPN.
Это не ' Так что решение "рабочая станция". Но если у вас есть возможность добавлять узлы (виртуальные машины или физические хосты) к каждому сайту (которые не обязательно должны быть частью производственной среды), то это может быть решением. Если у вас уже есть производственный DNS, который вам удобно изменять, то вы, возможно, уже сможете использовать имеющиеся представления и именование.
Можете ли вы сделать что-нибудь на удаленных сайтах, например, перетащить файл в $ HOME или отредактировать bashrc? Например, на одном сайте у меня есть / etc / bashrc:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[SITE1 \u@\h \W]\\$ "
, что помогает избежать двусмысленности. Вы можете настроить запрос на включение cat .site_name , например, если вы можете установить этот файл.
Также посмотрите на использование .ssh / config для определений имен хостов. Вы можете иметь:
Host app1.site1
HostName 10.11.12.13
User service
и т. Д. а затем используйте ssh app1.site1 и полагайтесь на строгую проверку ключа хоста для вашей безопасности. Я предполагаю, что sshd было разрешено создавать собственные ключи хоста. Если у машин одинаковые ключи хоста, у вас возникнут проблемы.
Наконец, вы можете написать сценарий оболочки ssh. Обратитесь к таблице маршрутизации ( netstat -nr ), чтобы найти конечные точки VPN и запретить неправильное поведение на основе IP конечной точки. Примерно: safe_ssh имя хоста сайта и, помимо ротации ваших файлов known_hosts, если место назначения для вашей удаленной сети не соответствует указанному вами значению сайта, выйдите из системы с сообщением об ошибке. Вероятно, вы могли бы что-нибудь придумать с мультиплексированием ssh-соединения, если бы вы хотели, чтобы сценарий также включал и отключал VPN.
Может ли дать каждой машине уникальный IP-адрес (а также общий IP-адрес, предположительно, согласно RFC 1918) решением? Мы используем этот подход, у нас есть несколько машин с псевдонимом IP в соответствии с RFC 1918, но все они имеют уникальный «общедоступный» IP.