Мой вопрос - это ответ на чужой вопрос. Я просто пытаюсь создать надежное безопасное соединение между системой Windows Server 2008 и клиентами, которые к ней обращаются. То, что у нас отлично работало в течение многих лет на Windows Server 2003 и Window Server 2008 R1, полностью прекратилось с помощью R2. Я работаю в предположении, что это связано с использованием SMB протоколы, но я не уверен. К счастью, ничто, к чему они обращаются, не требует особой защиты, но даже если это так, те же требования к имени пользователя и паролю, а также тот факт, что эти пользователи должны быть указаны на сервере, похоже, предотвращают любой несанкционированный доступ.
Тем не менее, мне удобнее использовать VPN и я недоумеваю, почему то, что раньше было "сделкой" с Windows, теперь потребует использования дополнительного оборудования для обеспечения рабочего интерфейса для VPN для подключения. Что случилось с нормальным RRAS настройки с Windows Server 2008R2?
Согласно текущим настройкам, пользователям всегда предлагается ввести имя пользователя и пароль. Все пользователи в системе настроены как обычные пользователи, а не как администраторы. Несколько проблем, с которыми я столкнулся, всегда связаны с блокировкой портов. доступ через \\ipaddress\sharedfolder где папка должна быть предоставлена пользователю, который к ней обращается. Пока что это, похоже, правильно наследует разрешения, и никто не может получить то, чего не должен.
Та же самая установка с использованием VPN также работал, но был намного больше проблем и не обеспечивал больше безопасности, так как все пользователи настаивают на том, чтобы шлюз был открыт на их стороне, чтобы позволить им доступ в Интернет и просмотр через своего местного провайдера. так что для начала это был только V "получастный" N.
Если у кого-то есть лучшая установка, я хотел бы знать, как это сделать. Это была чистая отчаянная попытка решить проблемы, возникшие после обновления до Windows Server 2008 R2. Кажется, что это работает так же, как они описывают новый прямой доступ, но без двойного NICs и активные контроллеры домена. Я хуже, чем «новичок», поэтому могу только сказать вам, что после недели «кровотечения из глаз» я наконец заставил сервер и клиентов «поговорить». Но это было с VPN.
Еще одна неделя проб и ошибок, прежде чем однажды я понял, что даже не использую VPN но у меня все еще был доступ. Результат - стабильное соединение из любого места без каких-либо VPN. Удаленные системы подключаются к серверу, как только они включаются, и подключаются к Интернету.
Иногда (примерно каждые 2 недели) пользователю предлагается ввести свой сетевой пароль, что меня устраивает, так как это гарантирует, что система все еще находится в руках владельца. Со стороны сервера кажется, что они связаны через локальную сеть.
Я вижу их, и они видят сервер, и это все, что мне нужно. у меня нет offline files включен, так что это тоже не то.
Все клиенты - это Windows 7, а сервер - Windows Server 2008 R2 Standard Edition. Если у кого-то еще есть подобная установка, я хотел бы знать, как я могу ее улучшить.
Для бонусные очки Я хотел бы, чтобы кто-нибудь мог объяснить мне, почему некоторые ноутбуки пользователей в некоторые местоположений, отображение дисков ДОЛЖНО выполняться как \\servername\shared папка. Но в других местах на том же ноутбуке сопоставление должно выполняться \\IP address\shared папка.
В обоих случаях это один и тот же ноутбук, подключенный к одному серверу и одной папке. Кроме того, даже места, которые НЕ будут отображаться IP, если я попытаюсь создать VPN, то VPN должен подключиться к IP. Он никогда не принимает имя хоста сервера.
Это должно быть каким-то образом связано с маршрутизатором или интернет-провайдером, потому что это зависит от местоположения. Если они перенесут свой ноутбук через улицу, он вернется к нормальной работе только с IP.
У нас нет WINS server и имя сервера хранятся только внутри самого сервера. Любой способ согласовать это с использованием только IP будет приветствоваться, так как мест, где отображение использует имя сервера, немного и далеко друг от друга, но все же достаточно, чтобы вызвать проблемы.
Разъяснения в ответ на @EvanAnderson:
У меня нет проблем с использованием VPN. Я хотел с самого начала дать понять, что я бы предпочел сделать это, если бы я мог заставить их работать. Мои проблемы в том, что VPNs больше не будет надежно работать с Windows Server 2008 R2. И я уверен, что в основе проблемы лежит недостаток знаний. Если бы я заранее знал об изменениях, которые были внесены между Windows Server 2008 и 2008 R2 (которые, как я предполагал, только что включали последние пакеты обновления для 2008 года), я бы никогда не сделал этого. Когда мы заказывали новую систему, я бы настаивал либо на R1, либо на установке сам, потому что R2 - это то место, где «упало дно».
В VPN Проблемы почти в каждом случае связаны с людьми, использующими «сотовые маршрутизаторы», обычно называемые устройствами MiFi. В местах, где еще есть VPN проблемы с проводными маршрутизаторами, это правда, что я отслеживал многие проблемы обратно к заблокированным портам и т. д. Однако я застрял в любом случае, потому что устройства MiFi не имеют возможности контролировать блоки портов (или если они неужели они не будут делиться ими со мной, я пробовал) или в отелях / мотелях / кондоминиумах и т. д., где, опять же, я практически не контролирую то, через что разрешено проходить.
В одном конкретном случае я провел целый день в большом жилом комплексе, где два разных пользователя не могли подключиться. Оказалось, что этот комплекс покупает у них доступ в Интернет «оптом» и перепродает его. Я не знаю достаточно подробностей, чтобы помочь, но я считаю, что либо концентраторы, либо другие усилители, используемые для привлечения большого количества пользователей к небольшой части полосы пропускания, в то время как у каждого пользователя все еще есть «свой» кабельный модем, каким-то образом вызывают проблема. Но никто не возьмется за дело, даже если до обновления R2 все работало нормально.
Вы совершенно правы в том, что установка, с которой я работал, «хуже», чем ужасная, но она, по крайней мере, вернула всех в сеть на достаточно долгое время, чтобы я успел изучить другие возможные решения. До сих пор мне кажется, что лучше всего сбросить Windows Server 2008 R2 и перезагрузить R1. К сожалению, это имеет неотъемлемый риск «сломать» то, что в настоящее время «работает», даже если это не так. право, поэтому я пытаюсь понять, смогу ли я «облегчить» правильное исправление, не удаляя Windows Server R2.
Это было то, что я надеялся найти здесь. Кто-то, кто мог сказать мне первым Зачем Windows Server 2008 R2 не удалось, и что я мог сделать, чтобы она заработала. Я все еще склоняюсь к SMB против NFS файловая структура. Мне жаль, что у меня еще не была рабочая система Windows Server 2008 R1, чтобы я мог проверить, какой протокол был используемый. К сожалению, он сидел здесь, когда мне передали элементы управления и приказы «держать его в рабочем состоянии 24/7/365, несмотря ни на что».
Еще один момент - VPN настроить. В Windows Server 2008 R1 под security, раньше мы проверяли оба CHAP и CHAP-V2. Только на Windows Server 2008 R2 CHAP-V2 работает; если CHAP даже проверено вообще, VPN не подключаюсь. Мы также ограничены PTPT только, IKE а другие вообще не подключаются, и это может быть нормально. Но сотовые устройства MiFi, старые маршрутизаторы и места, где они пытаются втиснуть слишком много людей в как можно меньше места, вот где возникли проблемы.
Если это хоть как-то поможет объяснить, почему вообще возникли проблемы с подключением, возможно, я смогу найти способ исправить это в Windows Server 2008 R2. Любая помощь или знания принимаются с благодарностью! Даже если этот совет состоит в том, чтобы просто вернуться к Windows Server 2008 R1 и не бороться с этим.
Похоже, вы получаете доступ к общим файловым ресурсам SMB на автономном (не входящем в домен) компьютере с Windows Server через Интернет без использования VPN. Это очень странная конфигурация, которую я бы никому не рекомендовал. Я не уверен, что понимаю, почему вы не хотите использовать VPN.
Вы обнаружите, что различные интернет-провайдеры, поставщики беспроводных точек доступа и т. Д. Блокируют NetBIOS через TCP и SMB через TCP (порты TCP 139 и 445 соответственно) в соответствии с политикой. Помимо безопасности, использование VPN позволяет вам устанавливать произвольную связь между вашими серверами и клиентами, не беспокоясь о том, что сетевые провайдеры фильтруют ваш трафик. Уже одного этого должно быть достаточно для использования VPN.
Разрешение имен через широковещательную рассылку NetBIOS (неквалифицированные имена) вообще не будет работать в Интернете. Разрешение DNS-имен будет работать (полное имя или неполное имя, если вы жестко установили DNS-суффикс на клиенте), если имя серверного компьютера разрешается в DNS. Указание имени сервера в качестве его IP-адреса в UNC всегда должно работать везде, где NetBIOS через TCP и / или SMB через TCP не блокируется.
Если вы собираетесь использовать VPN в Windows и хотите, чтобы разрешались неквалифицированные имена, вам нужно либо использовать WINS, либо настроить клиентов на уточнение имен на основе доменного имени серверного компьютера. Я чувствую, что отчасти ваше нежелание использовать VPN может быть связано с нечетким разрешением имен. Установка WINS-сервера будет иметь большое значение для улучшения работы разрешения имен через VPN.
Ваша архитектура здесь действительно, очень причудливая и вовсе не лучшая практика. Если ваши пользователи не могут справиться с использованием VPN, вы можете рассмотреть возможность использования IPSEC (хотя в вашей среде, не относящейся к домену, вам придется вручную настраивать множество вещей, чтобы это работало).