Работа с хранилищем конфигурации удаленно. Настройка сервера хранилища конфигураций

13 способов, как своими руками устранить неполадки подключений, по протоколу TCP/IP в Windows XP . (Only for "direct" hands - Только если обе руки не левые;))

Способ 1. Проверка конфигурации с помощью средства IPConfig

Чтобы проверить конфигурацию TCP/IP на компьютере, где обнаружена проблема , с помощью средства IPConfig , нажмите кнопку Пуск , выберите пункт Выполнить и введите команду cmd . Для получения сведений о конфигурации компьютера, включая его IP-адрес , маску подсети и шлюз по умолчанию , можно использовать программу ipconfig.

Если указать для IPConfig параметр /all , будет создан подробный отчет о конфигурации всех интерфейсов , включая адаптеры удаленного доступа . Отчет IPConfig можно записать в файл , что позволит вставлять его в другие документы . Для этого введите команду ipconfig > имя_папкиимя_файла В результате отчет будет сохранен в файле с указанным именем и помещен в указанную папку.

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

Если компьютер имеет IP-адрес 169.254.y.z и маску подсети 255.255.0.0, то IP-адрес был назначен средством автоматического назначения IP-адресов APIPA операционной системы Windows XP Professional. Это означает, что TCP/IP настроен для автоматической конфигурации , сервер DHCP не был найден и не была указана альтернативная конфигурация . В этой конфигурации для интерфейса не задан шлюз по умолчанию.

Если компьютер имеет IP-адрес 0.0.0.0, значит, он был переопределен средством опроса носителя DHCP. Это может быть вызвано тем, что сетевой адаптер не обнаружил подключения к сети , или тем, что протокол TCP/IP обнаружил IP-адрес, который дублирует присвоенный вручную адрес компьютера.

Если не удалось определить проблемы в конфигурации TCP/IP, перейдите к способу 2

Способ 2. Проверка подключения с помощью средства Ping

Если в конфигурации TCP/IP не было обнаружено ошибок, проверьте возможность подключения компьютера к другим компьютерам в сети TCP/IP. Для этого используется средство Ping.

С помощью средства Ping можно проверить подключение на уровне IP . Команда ping отправляет на другой компьютер сообщение с эхо-запросом по протоколу ICMP . С помощью средства Ping можно узнать, может ли главный компьютер отправлять IP-пакеты на компьютер-получатель. Команду Ping можно также использовать для выявления того, чем вызвана проблема – неполадкой сетевых устройств или несовместимостью конфигураций .

Примечание Если была выполнена команда ipconfig /all и отобразилась конфигурация IP, то адрес замыкания на себя и IP-адрес компьютера не нужно проверять с помощью команды Ping. Эти задачи уже были выполнены командой IPConfig при выводе конфигурации. При устранении неполадок следует убедиться, что существует маршрутизация между локальным компьютером и узлом сети. Для этого используется команда ping IP-адрес

Примечание IP-адрес является IP-адресом узла сети, к которому требуется подключиться.

Чтобы использовать команду ping, выполните следующие действия:

1. Задайте адрес замыкания на себя, чтобы проверить правильность настройки и установки TCP/IP на локальном компьютере. Для этого служит следующая команда: ping 127.0.0.1 Если контроль по обратной связи завершится ошибкой, это означает, что стек IP не отвечает.
Подобное поведение наблюдается в следующих случаях:
Повреждены драйвера TCP.
Не работает сетевой адаптер.
Другая служба мешает работе протокола IP.

2. Обратитесь по IP-адресу локального компьютера, чтобы убедиться в том, что он был правильно добавлен в сеть. Если таблица маршрутизации не содержит ошибок, эта процедура просто приведет к направлению пакета по адресу замыкания на себя 127.0.0.1.
Для этого служит следующая команда: ping IP-адрес локального узла Если контроль по обратной связи выполнен успешно, но локальный IP-адрес не отвечает, возможно, проблема заключается в таблице маршрутизации драйвера сетевого адаптера.

3. Обратитесь по IP-адресу шлюза по умолчанию, чтобы проверить его работоспособность и возможность связи с локальным узлом локальной сети. Для этого служит следующая команда: ping IP-адрес шлюза по умолчанию Если обращение завершилось неудачно, это может означать, что проблема заключается в сетевом адаптере , маршрутизаторе/шлюзе , кабеле или другом сетевом устройстве .

4. Обратитесь по IP-адресу удаленного узла , чтобы проверить возможность связи через маршрутизатор. Для этого служит следующая команда: ping IP-адрес удаленного узла. Если обращение завершилось неудачно, это может означать, что удаленный узел не отвечает или проблема заключается в сетевых устройствах между компьютерами. Чтобы исключить возможность отсутствия ответа удаленного узла, проверьте связь с другим удаленным узлом с помощью команды Ping.

5. Обратитесь по IP-адресу удаленного узла, чтобы проверить, может ли быть разрешено имя удаленного узла. Для этого служит следующая команда: ping имя удаленного узла Команда Ping использует разрешение имен для разрешения имени компьютера в IP-адрес. Поэтому, если обращение по IP-адресу производится успешно, а обращение по имени – неудачно, проблема заключается в разрешении имени узла, а не в сетевом подключении. Проверьте, настроены ли для компьютера адреса сервера DNS (вручную в свойствах TCP/IP или автоматически). Если адреса сервера DNS выводятся командой ipconfig /all, обратитесь по адресам сервера, чтобы проверить, доступны ли они.

Если на одном из этапов использования средства Ping возникают ошибки, выполните следующие действия:
Убедитесь, что IP-адрес локального компьютера действителен и правильно задан на вкладке Общие диалогового окна Свойства протокола Интернета (TCP/IP) или с помощью средства Ipconfig.
Убедитесь, что настроен шлюз по умолчанию и имеется связь между узлом и шлюзом по умолчанию. Для разрешения проблем должен быть настроен только один шлюз по умолчанию. Хотя шлюзов по умолчанию может быть несколько, все шлюзы кроме первого используются только тогда, когда стек IP определяет, что первый шлюз не работает. При устранении неполадок определяется состояние первого из настроенных шлюзов. Для облегчения задачи все остальные шлюзы можно удалить.
Убедитесь, что отключен протокол безопасности IPSec . При некоторых политиках IPSec пакеты Ping могут блокироваться или требовать защищенного подключения. Дополнительные сведения о протоколе IPSec см. в способе

7. Проверка протокола IPSec Внимание! Если соединение с удаленной системой, к которой происходит обращение, имеет большое время задержки (это относится, например, к спутниковой линии связи), возможно, ответа придется ждать дольше. С помощью параметра -w можно задать более продолжительный период ожидания, чем период по умолчанию, равный 4 секундам.

Способ 3 . Проверка маршрутизации с помощью средства PathPing

PathPing – это средство, выявляющее потери пакета на маршрутах, включающих несколько прыжков. Обратившись с помощью PathPing к удаленному узлу, можно убедиться, что маршрутизаторы, через которые проходит пакет, работают нормально. Для этого служит следующая команда: pathping IP-адрес удаленного узла

Способ 4 . Очистка кэша ARP с помощью средства Arp

Если обращение по адресу замыкания на себя (127.0.0.1) и собственному IP-адресу выполняется успешно, но ко всем остальным IP-адресам обратиться не удается, попытайтесь очистить кэш протокола ARP (Address Resolution Protocol , протокол разрешения адресов).
С помощью командной строки выполните одну из следующих команд.
arp -a (тоже самое arp -g)

Чтобы удалить записи, введите команду
arp -d IP-адрес

Для очистки кэша ARP используется следующая команда:
netsh interface ip delete arpcache

Способ 5 . Проверка шлюза по умолчанию

Способ 6 . Проверка связи с помощью средств Tracert или Route

Если шлюз по умолчанию отвечает правильно, обратитесь к удаленному узлу, чтобы убедится в правильной работе межсетевых соединений. Если эти соединения работают некорректно, проследите путь сообщения к получателю с помощью служебной программы Tracert. Для IP-маршрутизаторов , которые являются компьютерами с операционной системой Microsoft Windows 2000 или Microsoft Windows NT 4.0 , просмотрите таблицу IP-маршрутизации с помощью средства маршрутизации или оснастки «Маршрутизация и удаленный доступ» этих компьютеров. На других IP-маршрутизаторах для просмотра таблицы IP-маршрутизации используйте средство, указанное поставщиком используемой операционной системы.

В большинстве случаев при использовании команды Ping отображаются четыре следующих сообщения об ошибках: TTL
Expired in Transit Это сообщение об ошибке означает, что количество требуемых проходов через маршрутизатор превышает время жизни (TTL). Время жизни можно увеличить с помощью команды ping-i. Возможно, причина этой ошибки в том, что в маршрут является циклическим.

Чтобы узнать, действительно ли возник циклический маршрут (из-за неправильной конфигурации маршрутизаторов), используйте команду Tracert Destination Host Unreachable Это сообщение об ошибке означает, что к узлу-получателю нет локального или удаленного маршрута (на узле-отправителе или маршрутизаторе). Проверьте таблицу маршрутизации на локальном узле или маршрутизаторе.
Request Timed Out Это сообщение об ошибке означает, что сообщения с эхо-запросами не были получены в течение заданного периода ожидания. По умолчанию он равен 4 секундам. Период ожидания можно увеличить с помощью команды ping -w.
Ping request could not find host Это сообщение об ошибке означает, что не удается разрешить имя узла-получателя. Проверьте имя и доступность серверов DNS или WINS .

Способ 7 . Проверка протокола IPSec

IPSec может усилить безопасность в сети , но усложнить изменение конфигурации сети и устранение неполадок. В некоторых случаях политика IPSec требует защищенного подключения для компьютера под управлением Windows XP Professional. Это требование затрудняет установку подключения к удаленному узлу. Если службы IPSec развернуты на локальном узле , можно отключить их в оснастке «Службы».

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

Способ 8 . Проверка фильтрации пакетов

Ошибки при фильтрации пакетов могут нарушить работу системы разрешения адресов или подключения. Чтобы узнать, является ли фильтрация пакетов источником проблемы, отключите фильтрацию пакетов TCP/IP.

Для этого выполните следующие действия.

1. Нажмите кнопку Пуск и последовательно выберите пункты Панель управления, Сеть и подключения к Интернету и Сетевые подключения.
2. Щелкните правой кнопкой мыши значок подключения по локальной сети, которое требуется изменить, и выберите пункт Свойства.
3. На вкладке Общие в списке Отмеченные компоненты используются этим подключением выберите вариант Протокол Интернета (TCP/IP) и нажмите кнопку Свойства.
4. Нажмите кнопку Дополнительно и перейдите на вкладку Параметры.
5. В диалоговом окне Необязательные параметры выберите элемент Фильтрация TCP/IP и нажмите кнопку Свойства.
6. Снимите флажок Задействовать фильтрацию TCP/IP (все адаптеры) и нажмите кнопку OK. Попробуйте обратиться к адресу по его имени DNS , имени NetBIOS компьютера или IP-адресу. Если обращение выполнено успешно, возможно, параметры фильтрации были неправильно установлены или накладывают слишком жесткие ограничения. Например, фильтрация может разрешить компьютеру выступать в роли веб-сервера, но отключить ряд средств, таких как удаленное администрирование. Чтобы расширить диапазон допустимых параметров фильтрации, измените допустимые значения для порта TCP , порта UDP и протокола IP .

Способ 9 . Проверка подключения к определенному серверу

Чтобы определить причину проблемы при подключении к серверу через NetBIOS , выполните команду nbtstat -n на этом сервере. Это позволит узнать, под каким именем сервер зарегистрирован в сети.
Команда nbtstat -n выводит несколько имен, под которыми зарегистрирован компьютер . Среди этих имен должно быть имя, похожее на то, которое указано на вкладке Имя компьютера окна Система, доступного с панели управления. Если такого имени нет, попытайтесь использовать любое другое уникальное имя, выведенное командой nbtstat.
Средство Nbtstat также может отображать кэшированные записи удаленных компьютеров, которые отмечены #PRE в файле Lmhosts или относятся к недавно разрешенным именам.
Если удаленные компьютеры используют для сервера одно и то же имя, а другие компьютеры находятся в удаленной подсети, убедитесь, что для них задано соответствие «имя-адрес» в файлах Lmhosts или в серверах WINS .

Способ 10 . Проверка удаленных подключений

Чтобы определить, почему не устанавливается подключение по протоколу TCP/IP с удаленным компьютером, выполните команду netstat -a , показывающую состояние всех портов TCP и UDP локального компьютера.
Если подключение TCP работает нормально, в очередях Sent (Отправлено ) и Received (Получено ) отображается 0 байт.
Если в одной из этих очередей данные блокируются или они имеют состояние «irregular », подключение может быть неисправно.
Если данные не блокируются, а очереди находятся в состоянии «typical », то проблема, вероятно, вызвана задержкой в работе сети или программе.

Способ 11 . Проверка таблицы маршрутизации с помощью средства Route

Способ 12 . Проверка путей с помощью средства Tracert

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

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

Способ 13 . Устранение неполадок в шлюзах

Если при настройке было получено приведенное ниже сообщение, выясните, находится ли шлюз по умолчанию в той же логической сети, что и сетевой адаптер компьютера:
Your default gateway does not belong to one of the configured interfaces
Сравните часть IP-адреса шлюза по умолчанию, соответствующую идентификатору сети, с идентификаторами сети сетевых адаптеров компьютера. В частности, проверьте, равен ли результат логического поразрядного И IP-адреса и маски подсети результату логического поразрядного И основного шлюза и маски подсети.

Windows Server 2003, пока не ознакомитесь с сетевыми процессами, которые выполняются скрытым образом. В данной лекции дается обзор многих таких процессов, включая следующие темы.

• Использование TCP/IP в рамках сетевой модели Windows Server 2003
• Протоколы TCP/IP и уровни их функционирования
• Использование утилит TCP/IP Windows Server 2003

Понимание этих тем упрощает разрешение проблем TCP/IP в случае их возникновения.

Обзор TCP/IP

Расширение Windows до уровня сетевой операционной системы класса предприятия и огромная популярность интернета – вот два фактора, которые сделали протокол TCP/IP сетевым стандартом де факто в наше время. Сети предприятий стали более разнородными за последние годы как за счет ввода новых технологий, так и объединения существующих технологий, и одним из следствий этого явления стало общее увеличение перегрузки сетевого трафика из-за различных типов протоколов, используемых на различных платформах.

Чтобы справиться с этой перегрузкой, многие сетевые администраторы прибегли к стандартизации на основе какого-либо одного набора протоколов, чтобы им было проще управлять сетевым трафиком. По целому ряду причин наиболее очевидным комплектом протоколов является TCP/IP . В частности, это следующие причины.

• Совместимость . Большинство известных сетевых операционных систем в настоящее время могут использовать TCP/IP как собственный протокол. Остальные операционные системы явно уступают в их поддержке отраслевых стандартов.
• Масштабируемость . TCP/IP разрабатывали для использования в том, что стало теперь крупнейшей интерсетью, то есть в интернете. TCP/IP содержит протоколы, отвечающие почти любой задаче обмена информацией при различных уровнях скорости, объемах служебной информации и надежности.
• Разнородность (гетерогенность) . Комплект TCP/IP может поддерживать практически любое оборудование или платформу операционных систем, которые используются в настоящее время. Его модульная архитектура позволяет поддерживать новые платформы без переделки базовых протоколов.
• Адресуемость . Каждой машине в сети TCP/IP присваивается уникальный идентификатор, что делает ее адресуемой на любой другой машине в сети.
• Доступность . Протоколы TCP/IP предлагаются как открытые стандарты, которые могут использовать все, и они разрабатываются на основе "открытого форума", когда приветствуется вклад от любых заинтересованных сторон.

Рост популярности Windows в наши дни, в частности, объясняется использованием TCP/IP . Его предшественник, NETBEUI (собственный исходный протокол Windows NT), оказался недостаточным как протокол уровня предприятия, поскольку у него нет сетевого уровня, и поэтому он не поддерживает маршрутизацию между сегментами сети.

Использование TCP/IP в разработках Microsoft

Разработка протоколов TCP/IP для использования в сети ARPANET (которую позже переименовали в Internet) началась в 1970-х гг., но некоторые нововведения, которые сделали TCP/IP применимым для использования в частных сетях уровня предприятия, были осознаны много позже. Показательным случаем стало применение TCP/IP компанией Microsoft для ее собственной глобальной корпоративной интерсети.

В начале 1990-х гг., когда группа по информационным технологиям (Information Technology Group) компании Microsoft обсуждала различные протоколы, которые могли бы заменить "архаичные" протоколы XNS , TCP/IP был первым кандидатом с самого начала, но он содержал определенные серьезные препятствия для широкомасштабного развертывания по всему миру. Главными препятствиями были администрирование и конфигурирование IP-адресации, разрешения сетевых имен и использования широковещательных сообщений для поиска других компьютеров.

Даже в сети небольшого или среднего масштаба задача назначения IP-адресов является достаточно обременительной; но в крупной интерсети, охватывающей более 50 стран, это требует серьезных административных затрат. Требуется не только тщательно планировать назначения сетевых адресов и вести аккуратные записи в какой-либо центральной точке, но также справляться с задачей реального конфигурирования тысяч узлов. Вы смогли бы отправить обученный персонал в каждый удаленный офис? Обучить сотрудников, которые уже работают там? Разработать документацию, которая (как предполагается) позволит конечным пользователям сконфигурировать свои собственные рабочие станции?

Еще одной серьезной проблемой является разрешение имен при таком масштабе. Чтобы использовать TCP/IP с операционными системами Microsoft до Windows 2000, вам приходилось иметь средства сопоставления имен Net-BIOS с IP-адресами. В локальном сегменте сети это осуществлялось с помощью широковещательных сообщений (что само по себе могло создавать проблемы сетевого трафика). Для соединения с машинами в других сетях на каждой рабочей станции требовались записи файла LMHOSTS, где указывались имена NetBIOS и соответствующие IP-адреса. Задача поддержки этих файлов на таком большом числе компьютеров требует еще больших затрат, чем назначение IP-адресов.

Для сотрудников Microsoft было ясно, что трудности, с которыми они сталкиваются, будут возникать в определенной степени при любой реализации TCP/IP в крупной корпоративной сети. Результатом усилий Microsoft совместно с другими разработчиками сетей и производителями программных продуктов стали модули DHCP и WINS, которые предоставляли сетевым пользователям соответственно службы конфигурирования IP-адресов и разрешения имен. Используя эти службы, вы могли в огромной степени снизить административную нагрузку, возникающую в большой сети TCP/IP и избавить своих пользователей от необходимости знать что-либо о протоколах и IP-адресах.

Комплект TCP/IP сильно изменился с появлением Windows 2000 и последующим выпуском Windows Server 2003. В него вошло много новых средств и улучшений по сравнению с предыдущими реализациями. TCP/IP Windows Server 2003 был стандартизован. Он больше не основывается на NetBIOS для разрешения имен. Вместо этого основным механизмом разрешения имен является система доменных имен DNS (Domain Name System).

Термин TCP/IP не охватывает весь этот комплект. На самом деле это набор из более чем дюжины протоколов, а TCP и IP – это только два из них. Стандарты, на которых основываются эти протоколы, публикуются группой IETF (Internet Engineering Task Force) в форме документов RFC (requests for comments). Если вас интересуют документы RFC, начните с сайта IETF, www.ietf.org , откуда вы можете переходить на другие сайты, содержащие документы RFC. На большинстве сайтов эти документы хранятся в каталоге верхнего уровня под названием RFC. Это в основном ASCII-файлы, и некоторые документы содержат рисунки, доступные в формате PostScript.

Улучшения в TCP/IP Windows Server 2003

Как и почти для всего в компьютерном мире, в TCP/IP постоянно вносятся изменения и улучшения, отвечающие постоянно растущим деловым потребностям. В этом разделе описываются некоторые из новых технологий TCP/IP, включенные в Windows Server 2003 (многие из них появились впервые в Windows 2000, но представлены здесь как "новые" для тех, кто переходит к Windows Server 2003 из Windows NT).

IGMP Version 3

Протокол IGMP (Internet Group Management Protocol) Version 3 позволяет определять членство в группах для групповых сообщений. Хосты могут указывать, что они заинтересованы в получении трафика групповых сообщений из определенных источников. Это средство препятствует тому, чтобы поддерживающие групповую доставку маршрутизаторы не передавали групповой трафик в подсеть, где нет хостов, которым требуется получать групповой трафик.

Альтернативная конфигурация

Альтернативные конфигурации TCP/IP – это новая возможность для семейства Windows (Windows Server 2003 и Windows XP). Альтернативная конфигурация означает, что компьютер может иметь альтернативную конфигурацию TCP/IP – вручную сконфигурированный IP-адрес, который может использоваться в отсутствие сервера DHCP. Без альтернативной конфигурации TCP/IP использует по умолчанию средство автоматической IP-адресации Automatic Private IP Addressing (APIPA), чтобы назначить уникальный IP-адрес в диапазоне от 169.254.0.1 до 169.254.255.254 с маской подсети 255.255.0.0.

Возможность иметь альтернативную настройку – это преимущество типа "два средства по цене одного" для пользователей компьютеров, которые подсоединяются более чем к одной сети, в одной из которых или в обеих нет сервера DHCP. Например, мобильные пользователи часто подсоединяются к офисной сети, а также используют свои компьютеры в своих домашних сетях. Многие мобильные пользователи ездят в филиалы своих компаний или к клиентам, где им нужно подключаться к местным сетям. В одном из мест для лэптопа этого пользователя используется конфигурация TCP/IP, предусматривающая использование DHCP. В другом месте, если нет сервера DHCP, лэптоп автоматически использует альтернативную конфигурацию, выполняя доступ к устройствам домашней сети и к интернету. Такой пользователь имеет доступ к обеим сетям без необходимости изменения настроек TCP/IP вручную и последующей перезагрузки.

Хотя ваш компьютер Windows Server 2003 вряд ли является лэптопом, вам как администратору может потребоваться настройка компьютера Windows XP какого-либо пользователя для альтернативной конфигурации. Выполните для этого следующие шаги.

1. Откройте диалоговое окно Properties для объекта Local Area Connection (Соединение локальной сети).
2. Во вкладке General (Общие) выберите Internet Protocol (TCP/IP) и щелкните на кнопке Properties.
3. Выберите вариант Obtain an IP address automatically (Получать IP-адрес автоматически), что вызовет появление вкладки Alternate Configuration (Альтернативная конфигурация) в этом диалоговом окне.
4. Перейдите во вкладку Alternate Configuration (
   Рис. 1.2. Вручную отключите (Disable) или включите (Enable) NetBIOS over TCP/IP (NetBT)

   Автоматическое определение метрики маршрутизации

   Если у вас несколько интерфейсов, то по умолчанию TCP/IP теперь автоматически рассчитывает метрику маршрутизации, исходя из скорости интерфейса. Метрика интерфейса определяется как значение колонки Metric для таблицы маршрутизации. Это обеспечивает использование самого быстрого интерфейса для направления трафика к шлюзу по умолчанию.

В большинстве случаев 1С программист выполняет сложную разработку в офисе или дома, если это фрилансер, а затем приходит к заказчику и выкладывает доработки. Очень часто некоторые косяки исправляются прямо на месте. И конфигурация в офисе перестает быть равной конфигурации у заказчика. Нет ничего сложного взять копию базы, уходя от заказчика, но что если разработчиков несколько и ходят они к заказчику не дружной толпой, а по очереди.

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

Для решения этой задачи нам понадобиться:

1. хороший интернет на всех компьютерах, где идет разработка
2. компьютер, который виден из вне по белому IP

Как правило компьютер с белым IP – сервер в офисе. Начинать разворачивание хранилища конфигурации надо с его настройки. Первым делом поставим на него платформу 1С. При установке нужно указать наличие компоненты Сервер хранилища конфигурации. Обратите внимание на релиз платформы, дело в том, что при данной методике работы нужна одинаковая версия платформы, на всех компьютерах. И в вашем офисе, и дома, и у заказчика.

После установки, сам сервер хранилища в службах не появиться. Его надо зарегистрировать. Файл службы называется crserver.exe и лежит в каталоге bin .


Перед регистрацией надо определиться, в какой папке будет лежать наше хранилище. Сервер позволяет работать с несколькими хранилищами одновременно, поэтому серверу при регистрации мы указываем каталог, в котором будут лежать уже каталоги с хранилищами. Так же сервер прекрасно работает с русскими именами папок. Для дальнейшей функциональности было бы неплохо (но не обязательно), чтобы эта папка была расшарена. Например у нас есть общая папка на диске «Обмен», создадим в ней подкаталог «Хранилища».

Теперь регистрируем службу сервера хранилищ. Для этого жмем «пуск», «выполнить», набираем «cmd», жмем Enter и в командной строке пишем:
"C:\Program Files (x86)\1cv8\8.3.4.408\bin\crserver.exe" -instsrvc -d "C:\Обмен\Хранилища"

Если никаких сообщений об ошибке не вылезло, то в списке служб должна появится наша. В этом надо убедиться визуально.

Тут надо убедиться, что служба запущена и что у неё стоит автозапуск. Поскольку при регистрации мы не указали пользователя, то запускается она под системной учетной записью. Это удобно, но возможно не безопасно, при необходимости исправьте это в свойствах службы.
Теперь нам надо создать хранилище. Эта процедура долгая, поэтому рекомендую делать это в локальной сети, где находится наш сервер. Создаем, его как обычно, только в строке с путём указываем не сетевую папку, а путь в следующем формате:
tcp://Server1C/ХранилищеПроекта1\

Где Server1C – имя компьютера в локальной сети. Можно указать IP адрес этого компьютера. ХранилищеПроекта1 – имя каталога для нового хранилища. После создания на сервере хранилище будет лежать в папке C:\Обмен\Хранилища\ХранилищеПроекта1 .

Хоть мы и используем сервер хранилищ, но по своей сути это та же файловая база формата 1CD и к ней можно подключиться старым способом, указав в строке подключения сетевой каталог:
\\Server1C\Обмен\Хранилища\ХранилищеПроекта1

Тут есть несколько нюансов:
1. При работе по tcp с файлом базы работает процесс запущенный относительно файла локально, что обеспечивает некую надежность. Ранее я писал, что даже из-за использования wi-fi база хранилища может посыпаться, печальный опыт был. В этом случае система становится более устойчива к сбоям в сети.
2. При работе по tcp нужны одинаковые версии релизов платформы у всех участников, при файловом общении – нет.
3. Общая папка – папка с полным доступом для всех участников. Люди запросто могут случайно (а может и не случайно) накидать туда мусора, стереть пару «не нужных» файлов, в общем нагадить.

Исходя из этих нюансов, возможно есть смысл даже внутри локальной сети в некоторых случаях разворачивать сервер хранилища.
Теперь о доступе из вне. Сервер хранилищ работает на порту 1542. Если внешний белый IP адрес указывает непосредственно на Ваш сервер, то нужно позаботиться об открытии этого порта. Если внешний IP указывает на роутер, то надо настроить проброску. В моем случае была проброска, сисадмин выдели свободный порт для этого. У меня строка подключения выглядела так:
tcp://36.21.65.20:1501/ХранилищеПроекта1\

Комфорт работы с таким хранилищем полностью зависит от скорости интернета, поэтому всякие там usb модемы в модульных помещениях (почти всех торговых центрах) – плохая практика. Если в модеме нет стабильного 3G и он постоянно переходит на GPRS, то я бы даже не стал пытаться.

Еще, на последок, расскажу об обновлении платформы. Т.к. свежая 1С 8.3 сейчас выходит часто, то это актуально. Переустанавливать платформу надо везде сразу, это и так ясно. При переустановке на сервере служба автоматом не обновиться. Если делать все по правильному, т.е. зарегистрировать приложение crserver.exe из папки bin со свежим релизом платформы, то т.к. называется служба так же, то старая служба пометится на удаление, потребуется перезагрузка сервера. Можно поступить проще. Заходим в службы, останавливаем сервер хранилищ. Смотрим в свойствах строку запуска и копируем её в буфер обмена. Лезем в редактор реестра (regedit ) и ищем в реестре эту строку. Правим в ней номер релиза (он присутсвует в имени папки). Запускаем службу обратно. Все. Если Вы накосячили, то служба у Вас не запуститься. После запуска зайдите в свойства службы и визуально убедитесь, что она стартанула из папки с новым релизом.

На сегодня все, спасибо за внимание

Методические указания

Диагностические утилиты TCP/IP.

В состав TCP/IP входят диагностические утилиты, предназначенные для проверки конфигурации стека и тестирования сетевого соединения.

Утилита	Применение
hostname	Выводит имя локального хоста. Используется без параметров.
ipconfig	Выводит значения для текущей конфигурации стека TCP/IP: IP-адрес, маску подсети, адрес шлюза по умолчанию, адреса WINS (Windows Internet Naming Service) и DNS (Domain Name System)
ping	Осуществляет проверку правильности конфигурирования TCP/IP и проверку связи с удаленным хостом.
tracert	Осуществляет проверку маршрута к удаленному компьютеру путем отправки эхо-пакетов протокола ICMP (Internet Control Message Protocol). Выводит маршрут прохождения пакетов на удаленный компьютер.
arp	Выводит для просмотра и изменения таблицу трансляции адресов, используемую протоколом разрешения адресов ARP (Address Resolution Protocol - определяет локальный адрес по IP-адресу)
route	Модифицирует таблицы маршрутизации IP. Отображает содержимое таблицы, добавляет и удаляет маршруты IP.
netstat	Выводит статистику и текущую информацию по соединению TCP/IP.
nslookup	Осуществляет проверку записей и доменных псевдонимов хостов, доменных сервисов хостов, а также информации операционной системы, путем запросов к серверам DNS.

Проверка правильности конфигурации TCP/IP с помощью ipconfig.

При устранении неисправностей и проблем в сети TCP/IP следует сначала проверить правильность конфигурации TCP/IP. Для этого используется утилита ipconfig.

Эта команда полезна на компьютерах, работающих с DHCP (Dynamic Host Configuration Protocol), так как дает пользователям возможность определить, какая конфигурация сети TCP/IP и какие величины были установлены с помощью DHCP.

Синтаксис:

ipconfig | /release]

Параметры:

all выдает весь список параметров. Без этого ключа отображается только IP-адрес, маска и шлюз по умолчанию;

renew обновляет параметры конфигурации DHCP для указанного сетевого адаптера;

release освобождает выделенный DHCP IP-адрес;

adapter – имя сетевого адаптера;

displaydns выводит информацию о содержимом локального кэша клиента DNS, используемого для разрешения доменных имен.

Таким образом, утилита ipconfig позволяет выяснить, инициализирована ли конфигурация и не дублируются ли IP-адреса:

· если конфигурация инициализирована, то появляется IP-адрес, маска, шлюз;

· если IP-адреса дублируются, то маска сети будет 0.0.0.0;

· если при использовании DHCP компьютер не смог получить IP-адрес, то он будет равен 0.0.0.0 .

2. Тестирование связи с использованием утилиты ping .

Утилита ping (Packet Internet Grouper) используется для проверки конфигурирования TCP/IP и диагностики ошибок соединения. Она определяет доступность и функционирование конкретного хоста. Использование ping лучший способ проверки того, что между локальным компьютером и сетевым хостом существует маршрут. Хостом называется любое сетевое устройство (компьютер, маршрутизатор), обменивающееся информацией с другими сетевыми устройствами по TCP/IP.

Команда ping проверяет соединение с удаленным хостом путем посылки к этому хосту эхо-пакетов ICMP и прослушивания эхо-ответов. Ping ожидает каждый посланный пакет и печатает количество переданных и принятых пакетов. Каждый принятый пакет проверяется в соответствии с переданным сообщением. Если связь между хостами плохая, из сообщений ping станет ясно, сколько пакетов потеряно.

Ping можно использовать для тестирования как имени хоста (DNS или NetBIOS), так и его IP-адреса. Если ping с IP-адресом выполнилась успешно, а с именем – неудачно, это значит, что проблема заключается в распознавании соответствия адреса и имени, а не в сетевом соединении.

Утилита ping используется следующими способами:

1) Для проверки того, что TCP/IP установлен и правильно сконфигурирован на локальном компьютере, в команде ping задается адрес петли обратной связи (loopback address): ping 127.0.0.1

Если тест успешно пройден, то вы получите следующий ответ:

<1мс TTL=128

Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128

Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128

Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128

2) Чтобы убедиться в том, что компьютер правильно добавлен в сеть и IP-адрес не дублируется, используется IP-адрес локального компьютера:

ping IP-адрес_локального_хоста

3) Чтобы проверить, что шлюз по умолчанию функционирует и что можно установить соединение с любым локальным хостом в локальной сети, задается IP-адрес шлюза по умолчанию:

ping IP-адрес_шлюза

4) Для проверки возможности установления соединения через маршрутизатор в команде ping задается IP-адрес удаленного хоста:

ping IP-адрес_удаленного хоста

Синтаксис:

ping [-t] [-a] [-n count] [-l length] [-f] [-i ttl] [-v tos] [-r count] [-s count] [ [-j host-list] |

[-k host-list] ] [-w timeout] destination-list

Параметры:

T выполняет команду ping до прерывания. Control-Break - посмотреть статистику и продолжить. Control-C - прервать выполнение команды;

A позволяет определить доменное имя удаленного компьютера по его IP-адресу;

N count посылает количество пакетов ECHO, указанное параметром count;

L length посылает пакеты длиной length байт (максимальная длина 8192 байта);

F посылает пакет с установленным флагом «не фрагментировать». Этот пакет не будет фрагментироваться на маршрутизаторах по пути своего следования;

I ttl устанавливает время жизни пакета в величину ttl (каждый маршрутизатор уменьшает ttl на единицу);

V tos устанавливает тип поля «сервис» в величину tos;

R count записывает путь выходящего пакета и возвращающегося пакета в поле записи пути. Count - от 1 до 9 хостов;

S count позволяет ограничить количество переходов из одной подсети в другую (хопов). Count задает максимально возможное количество хопов;

J host-list направляет пакеты с помощью списка хостов, определенного параметром host-list. Последовательные хосты могут быть отделены промежуточными маршрутизаторами (гибкая статическая маршрутизация). Максимальное количество хостов в списке, позволенное IP, равно 9;

K host-list направляет пакеты через список хостов, определенный в host-list. Последовательные хосты не могут быть разделены промежуточными маршрутизаторами (жесткая статическая маршрутизация). Максимальное количество хостов – 9;

W timeout указывает время ожидания (timeout) ответа от удаленного хоста в миллисекундах (по умолчанию – 1сек);

destination-list указывает удаленный хост, к которому надо направить пакеты ping.

Пример использования утилиты ping:

C:\WINDOWS>ping –n 10 www.netscape.com

Обмен пакетами с www.netscape.com по 32 байт:

Ответ от 205.188.247.65: число байт=32 время=194мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=240мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=173мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=250мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=187мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=239мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=263мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=230мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=185мс TTL=48

Ответ от 205.188.247.65: число байт=32 время=406мс TTL=48

Статистика Ping для 205.188.247.65:

Пакетов: послано = 10, получено = 10, потеряно = 0 (0% потерь)

Наименьшее = 173мс, наибольшее = 406мс, среднее =236мс

В случае невозможности проверить доступность хоста утилита выводит информацию об ошибке. Ниже приведен пример ответа утилиты ping при попытке послать запрос на несуществующий хост.

Обмен пакетами с 172.16.6.21 по 32 байт:

Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

Статистика Ping для 172.16.6.21:
Пакетов: отправлено = 4, получено = 0, потеряно = 4 (100% потерь),

Приблизительное время передачи и приема:
наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс

Утилита сообщает не об отсутствии хоста, а о том, что за отведенное время не был получен ответ на посланный запрос. Причиной этого не обязательно является отсутствие хоста в сети. Проблема может крыться в сбоях связи, перегрузке или неправильной настройке маршрутизаторов и т. п. Ошибка «сеть недоступна» (network unreachable) прямо указывает на проблемы маршрутизации.

3. Изучение маршрута между сетевыми соединениями с помощью утилиты tracert .

Tracert - это утилита трассировки маршрута. Она использует поле TTL (time-to-live, время жизни) пакета IP и сообщения об ошибках ICMP для определения маршрута от одного хоста до другого.

Утилита tracert может быть более содержательной и удобной, чем ping, особенно в тех случаях, когда удаленный хост недостижим. С помощью нее можно определить район проблем со связью (у Internet-провайдера, в опорной сети, в сети удаленного хоста) по тому, насколько далеко будет отслежен маршрут. Если возникли проблемы, то утилита выводит на экран звездочки (*), либо сообщения типа «Destination net unreachable», «Destination host unreachable», «Request time out», «Time Exeeded».

Утилита tracert работает следующим образом: посылается по 3 пробных эхо-пакета на каждый хост, через который проходит маршрут до удаленного хоста. На экран при этом выводится время ожидания ответа на каждый пакет (Его можно изменить с помощью параметра -w). Пакеты посылаются с различными величинами времени жизни. Каждый маршрутизатор, встречающийся по пути, перед перенаправлением пакета уменьшает величину TTL на единицу. Таким образом, время жизни является счетчиком точек промежуточной доставки (хопов). Когда время жизни пакета достигнет нуля, предполагается, что маршрутизатор пошлет в компьютер-источник сообщение ICMP “Time Exeeded” (Время истекло). Маршрут определяется путем посылки первого эхо-пакета с TTL=1. Затем TTL увеличивается на 1 в каждом последующем пакете до тех пор, пока пакет не достигнет удаленного хоста, либо будет достигнута максимально возможная величина TTL (по умолчанию 30, задается с помощью параметра -h).

Маршрут определяется путем изучения сообщений ICMP, которые присылаются обратно промежуточными маршрутизаторами.

Примечание: некоторые маршрутизаторы просто молча уничтожают пакеты с истекшим TTL и не будут видны утилите tracert.

Синтаксис:

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] имя_целевого_хоста

Параметры:

D указывает, что не нужно распознавать адреса для имен хостов;

H maximum_hops указывает максимальное число хопов для того, чтобы искать цель;

J host-list указывает нежесткую статическую маршрутизацию в соответствии с host-list;

W timeout указывает, что нужно ожидать ответ на каждый эхо-пакет заданное число мсек.

4. Утилита arp .

Основная задача протокола ARP – трансляция IP-адресов в соответствующие локальные адреса. Для этого ARP-протокол использует информацию из ARP-таблицы (ARP-кэша). Если необходимая запись в таблице не найдена, то протокол ARP отправляет широковещательный запрос ко всем компьютерам локальной подсети, пытаясь найти владельца данного IP-адреса. В кэше могут содержаться два типа записей: статические и динамические. Статические записи вводятся вручную и хранятся в кэше постоянно. Динамические записи помещаются в кэш в результате выполнения широковещательных запросов. Для них существует понятие времени жизни. Если в течение определенного времени (по умолчанию 2 мин.) запись не была востребована, то она удаляется из кэша.

Синтаксис:

arp [-s inet_addr eth_addr] | [-d inet_addr] | [-a]

Параметры:

S занесение в кэш статических записей;

D удаление из кэша записи для определенного IP-адреса;

A просмотр содержимого кэша для всех сетевых адаптеров локального компьютера;

inet_addr - IP-адрес;

eth_addr - MAC-адрес.

5. Утилита route.

Утилита route предназначена для работы с локальной таблицей маршрутизации. Она имеет следующий

Синтаксис:
route [-f] [-p] [команда [узел] [шлюз] ]

Параметры:

F Очистка таблицы маршрутизации.

P При указании совместно с командой ADD создает постоянную запись, которая сохраняется после перезагрузки компьютера. По умолчанию записи таблицы маршрутов не сохраняются при перезагрузке.

команда одна из четырех команд:

PRINT - вывод информации о маршруте;

ADD - добавление маршрута;

DELETE - удаление маршрута;

CHANGE - изменение маршрута.

узел адресуемый узел

маска маска подсети; по умолчанию используется маска 255.255.255.255

шлюз адрес шлюза

метрика метрика маршрута;

интерфейс идентификатор интерфейса, который будет использован для пересылки пакета

Для команд PRINT и DELETE возможно использование символов подстановки при указании адресуемого узла или шлюза. Параметр шлюза для этих команд может быть опущен.

При добавлении и изменении маршрутов утилита route осуществляет проверку введенной информации на соответствие условию (УЗЕЛ & МАСКА) == УЗЕЛ. Если это условие не выполняется, то утилита выдает сообщение об ошибке и не добавляет или не изменяет маршрут.

Утилита осуществляет поиск имен сетей в файле networks. Поиск имен шлюзов осуществляется в файле hosts. Оба файла расположены в папке %systemroot%\system32\drivers\etc. Наличие и заполнение этих файлов не обязательно для нормального функционирования утилиты route и работы маршрутизации.

Хотя в большинстве случаев на рабочей станции это не требуется, можно вручную редактировать таблицы маршрутизации.

Пример использования утилиты route:

Добавление статического маршрута:
route add 172.16.6.0 MASK 255.255.255.0 172.16.11.1 METRIC 1 IF 0x1000003

6. Утилита netstat .

Утилита netstat позволяет получить статическую информацию по некоторым из протоколов стека (TCP, UDP, IP, ICMP), а также выводит сведения о текущих сетевых соединениях. Особенно она полезна на брандмауэрах, с ее помощью можно обнаружить нарушения безопасности периметра сети.

Синтаксис:

netstat [-a] [-e] [-n] [-s] [-p protocol] [-r]

Параметры:

A выводит перечень всех сетевых соединений и прослушивающихся портов локального компьютера;

E выводит статистику для Ethernet-интерфейсов (например, количество полученных и отправленных байт);

N выводит информацию по всем текущим соединениям (например, TCP) для всех сетевых интерфейсов локального компьютера. Для каждого соединения выводится информация об IP-адресах локального и удаленного интерфейсов вместе с номерами используемых портов;

S выводит статистическую информацию для протоколов UDP, TCP, ICMP, IP. Ключ «/more» позволяет просмотреть информацию постранично;

R выводит содержимое таблицы маршрутизации.

7. Утилита nslookup .

Утилита nslookup предназначена для диагностики службы DNS, в простейшем случае - для выполнения запросов к DNS-серверам на разрешение имен в IP-адреса. В общем случае утилита позволяет просмотреть любые записи DNS-сервера:

A – каноническое имя узла, устанавливает соответствие доменного имени ip-адресу.

SOA – начало полномочий,начальная запись, единственная для зоны;

MX – почтовыесерверы (хосты, принимающие почту для заданного домена);

PTR – указатель (служит для обратного преобразования ip-адреса в символьное имя хоста)

Утилита nslookup достаточно сложна и содержит свой собственный командный интерпретатор.

В простейшем случае (без входа в командный режим) утилита nslookup имеет следующий

Cинтаксис:
nslookup хост [сервер]

Параметры:

Хост DNS-имя хоста, которое должно быть преобразовано в IP-адрес.

Сервер Адрес DNS-сервера, который будет использоваться для разрешения имени. Если этот параметр опущен, то будут последовательно использованы адреса DNS-серверов из параметров настройки протокола TCP/IP.

Примеры использования утилиты nslookup:

1. Получение списка серверов имен для домена yandex.ru без входа в командный режим (с использованием ключей).

C:\> nslookup -type=ns yandex.ru
Server: dns01.catv.ext.ru

Address: 217.10.44.35

Non-authoritative answer:

2. Получение записи SOA домена yandex.ru с авторитетного сервера с использование командного интерпретатора nslookup.

Default Server: dns04.catv.ext.ru

Address: 217.10.39.4

> set type=SOA

> server ns2.yandex.ru

Default Server: ns2.yandex.ru

Address: 213.180.199.34

Server: ns1.yandex.ru

Address: 213.180.193.1

primary name server = ns1.yandex.ru

responsible mail addr = sysadmin.yandex-team.r

serial = 2009022707

refresh = 1800 (30 mins)

retry = 900 (15 mins)

expire = 2592000 (30 days)

default TTL = 900 (15 mins)

yandex.ru nameserver = ns5.yandex.ru

yandex.ru nameserver = ns1.yandex.ru

yandex.ru nameserver = ns4.yandex.ru

yandex.ru nameserver = ns2.yandex.ru

ns1.yandex.ru internet address = 213.180.193.1

ns2.yandex.ru internet address = 213.180.199.34

ns5.yandex.ru internet address = 213.180.204.1

3. Получение адреса почтового сервера для домена yandex.ru.

C:\ >nslookup

Default Server: dns01.catv.ext.ru

Address: 217.10.44.35

Server: dns01.catv.ext.ru

Address: 217.10.44.35

Non-authoritative answer:

yandex.ru MX preference = 10, mail exchanger = mx2.yandex.ru

yandex.ru MX preference = 10, mail exchanger = mx3.yandex.ru

yandex.ru MX preference = 10, mail exchanger = mx1.yandex.ru

yandex.ru nameserver = ns2.yandex.ru

yandex.ru nameserver = ns1.yandex.ru

yandex.ru nameserver = ns4.yandex.ru

yandex.ru nameserver = ns5.yandex.ru

mx1.yandex.ru internet address = 77.88.21.89

mx2.yandex.ru internet address = 93.158.134.89

mx3.yandex.ru internet address = 213.180.204.89

ns2.yandex.ru internet address = 213.180.199.34

ns4.yandex.ru internet address = 77.88.19.60

ns5.yandex.ru internet address = 213.180.204.1

Указав ключ type=any, можно получить все записи о узле или домене. Ключи querytype, t, q эквивалентны type.

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

3. Протокол управления передачей (TCP) и Межсе евой протокол (IP)

4. DHCP - что это такое (IP навигатор или " абочая лошадка" сисадмина)?

5. Настройка конфигураций вруч ую и автоматическая конфигурация

История развития Сети

Предпосылки

Зарождение предпосылок создания глобальной Сети происходило в полном соответствий с глобальным философским законом о превращении количественных изменении в качественные. Как известно в период с 1945-1960 гг. в СССР и США проводились работы не только по созданию компьютеров, но и по интерактивному взаимодействию человека с машиной. В результате появились первые интерактивные устройства и вычислительные машины, работающие в режиме разделения времени. Правда, кого-то при этом щедро финансировали, а кто-то был иногда работать чуть ли не в подполье. Нашим ученым приходилось соблюдать конспирацию, дабы их не заподозрили в симпатий к "лженауке кибернетике". А ведь именно так определил новую науку советский научный словарь, изданный в середине XX века! Быть может, отголоски той эпохи можно встретить в отечественном термине ЭВМ, что, как известно, означает "электронно-вычислительная машина" и, как можно предположить, вполне сродни выражение "деревянно-письменный стол".

В 1957 г. в США, по указанию президента Дуайта Эйзенфаура, в составе Отдела Обороны (DoD, Department of Defence) формируется два правительственных органа: Национальная аэрокосмическая администрация NASA (National Aeronautics and Space Administration), которая в представлений не нуждается, а также Агентство по Передовым Оборонным Исследованиям (DAPRA или Defence Advanced Research Projects Agency). Сделано это было с целью продвижения военных технологий США на лидирующие позиций в мире.

Прогресс человечества и военные технологий всегда идут вместе, поэтому весь начальный этап развития нарождающей Сети будет связан с военными ведомством США. В начале 60-х годов основные работы DAPRA были посвящены разработке метода соединений компьютеров друг с другом. Агентство выделяет денежные средства для привлечения к перспективным разработкам университетов и корпораций (Массачусетский Технологический Институт -MIT, некоммерческая организация, занимающаяся стратегическими исследованиями и разработками -RAND Corporation).

В 1962 г. Дж. Ликлайдер (J.C.R. Liclider) публикует работу "Galactic Network", в котором предсказывает возможность существования в будущем глобальной компьютерной связи между людьми, имеющими мгновенный доступ к программам и базам данных из любой точки земного шара. Как это не удивительно, его предвидение в полном мере отражало современное устройство всемирной Сети. Тогда же, в августе 1962 г., вышла статья Дж. Ликлайдера и В. Сларка "Интерактивная связь человека с компьютером".

Возглавим первую исследовательскую программу, начатую DAPRA 4 октября 1962 г. Ликлайдер сумел увлечь своей концепцией группу ученых, среди которых был и его преемник- исследователь из MIT Лоуренс Робертс (Lowrence G. Roberts), а также Ивана Сазерленда (Ivan Sutherland) и Боба Тейлора (Bob Taylor).

В июле 1961 г. Леонард Клейнрок (Leonard Kleinrock) разработал и впервые опубликовал статью "Информационный поток в крупных коммутационных Сетях", где представил новую теорию передачи данных. Это была первая публикация по теорий коммутаций пакетов. В 1964 г. новая концепция вышла уже в книге. Тогда же Л. Клейнрок убедил Л. Робертса в возможности коммуникаций с использованием пакетов и в преимуществах своей теорий перед древнейшим принципом коммутаций каналов. Как известно, при пакетной коммутаций необходимые для передачи данные разбиваются на фрагменты, к каждому из которых присоединяется заголовок (адрес), одержащий полную информацию о доставке пакета по назначению. В результате один канал связи может использоваться для одновременно передачи данных множества пользователей, тогда как при коммутаций каналов, широко используемой в традиционной телефонной связи, канал связи выделяется исключительно к услугам двух пользователей, расположенные на его концах.

В преддверии

Для проверки новой концепций пакетной коммутаций Л. Робертс и Т. Мерилл еще в 1965 г. соединили компьютер TX-2 в штате Массачусетс (MIT, Лабораторий Линкольна) с компьютером Q-32 в System Development Corporation (Санта-Моника, Калифорния) с помощью низкоскоростных телефонных коммутируемых линий (пока еще без коммутаций пакетов).

Таким образом, в 1965 г. в США была создана первая в историй маленькая, но вовсе даже нелокальная компьютерная сеть. Результатом эксперимента стало понимание того, что компьютеры могут успешно работать вместе, выполняя программы и осуществляя выборку данных. Стало также ясным и то, что телефонная сеть с коммутацией каналов абсолютно непригодна для построения компьютерной сети. Разумеется, Л. Клейнрок еще раз убедился в необходимости пакетной коммутаций, и это было в тот момент самым главным.

В конце 1966 г. DARPA пригласило Л. Робертса для реализаций проекта компьютерной сети ARPANET. Целями проекта были объединения исследовательских учреждений, проведение экспериментов в области компьютерной коммуникаций, а также изучение способов поддержки надежной связи в условиях ядерного нападения.

Итак, Л. Робертс начал работать над разработкой концепций децентрализованного (распределенного) управления военными и гражданскими объектами в период ведения войн. Довольно быстро появился план ARPANET. В 1967 г. на симпозиуме по Принципам Взаимодействия (Operating Principles), организованной Ассоциацией машинных вычислений (ACM, Association for Computing Machinery), которая была основана еще 1947 г. и является первым научным и образовательным компьютерным сообществом, был представлен проект сети с коммутацией пакетов. И тогда же, в 1967 г. первое издание проекта ARPANET опубликовано Л. Робертсом.

В 1964 г. группа сотрудников RAND Corporation написала статью по сетям с пакетной коммутацией для надежных голосовых коммуникаций в военных системах. Работы, которые проводились в середине 60-х годах в MIT, RAND, и NPL, были во многом параллельными, и эти организаций не имели информации о деятельности друг друга. Разговор Л. Робертса с сотрудниками NPL увенчался заимствованием слова "пакет" и решение увеличить предлагаемую скорость передачи по каналам проектируемой сети ARPANET с 2,4 Кб/с до 50 Кб/с.

В конце 1969 г. в одну компьютерную сеть были включены четыре исследовательских центра:

University of California Los Angeles (UCLA);

Stanford Research Institute (SRI);

University of California at Santa Barbara (UCSB);

University of Utah.

Рождение

В октябре 1969 г. было послано первое электронное сообщение между узлами UCLA (Калифорнийский Университет, Лос-Анджелес) и SRI (Исследовательский Институт Стэнфорда). Говорят, что в самом начале работы эта сеть сразу же "зависла", но процесс пошел.

Вот так четыре удаленных компьютера были объединены в первоначальную конфигурацию ARPANET. Так, собственно и началось становление и рост Internet"а, которому уже, если можно считать, 33 года. Одновременно Р. Кан разработал общую архитектуру сети ARPANET, Л. Робертс разработал топологию и экономические вопросы, Л. Клейнрок представил все средства измерений и анализа сети.

Так и завершился начальный этап становления Интернета.

Основные понятия о Сети

Локальная сеть представляет собой набор компьютеров, периферийных устройств (принтеров и т. п.) и коммутационных устройств, соединенных кабелями.

Подавляющая часть компьютеров западного мира объединена в ту или иную сеть. Опыт эксплуатации сетей показывает, что около 80% всей пересылаемой по сети информации замыкается в рамках одного офиса. Поэтому особое внимание разработчиков стали привлекать так называемые локальные вычислительные сети (LAN). Локальные вычислительные сети отличаются от других сетей тем, что они обычно ограничены умеренной географической областью (одна комната, одно здание, один район).

Существует два типа компьютерных сетей: одноранговые сети и сети с выделенным сервером. Одноранговые сети не предусматривают выделение специальных компьютеров, организующих работу сети. Каждый пользователь, подключаясь к сети, выделяет в сеть какие-либо ресурсы (дисковое пространство, принтеры) и подключается к ресурсам, предоставленным в сеть другими пользователями. Такие сети просты в установке, налаживании; они существенно дешевле сетей с выделенным сервером. В свою очередь сети с выделенным сервером, несмотря на сложность настройки и относительную дороговизну, позволяют осуществлять централизованное управление.

И все компьютерные сети или практически применяют (если так можно назвать базовые топологий) построения локальной сети:

Топология «Шина»

Все компьютеры подключаются к одному кабелю. На его концах должны быть расположены терминаторы. По такой топологии строятся 10 Мегабитные сети 10Base-2 и10Base-5. В качестве кабеля используется Коаксиальные кабели.

Рис.1. Топология «Шина»

Пассивная топология, строится на использовании одного общего канала связи и коллективного использования его в режиме разделения времени. Нарушение общего кабеля или любого из двух терминаторов приводит к выходу из строя участка сети между этими терминаторами (сегмент сети). Отключение любого из подключенных устройств на работу сети никакого влияния не оказывает. Неисправность канала связи выводит из строя всю сеть Все компьютеры в сети “слушают” несущую и не участвуют в передаче данных между соседями. Пропускная способность такой сети снижается с увеличением нагрузки или при увеличении числа узлов.