8187
Комментарий: Ожидаются скриншоты.
|
← Версия 37 от 2008-10-09 21:22:15 ⇥
10060
No more illustration needed.
|
Удаления помечены так. | Добавления помечены так. |
Строка 2: | Строка 2: |
=== Proxy === Следующий пункт меню: прокси-сервер. Сам этот термин буквально означает "ретранслятор". Применяются ретрансляторы в следующей ситуации: пусть некоторая группа компьютеров в локальной сети подключена к Интернету через маршрутизатор. В самой сети компьютеры имеют адреса из диапазона, скажем, `10.0.0.0/8`. Как известно, пакеты с такими адресами не маршрутизируются в Интернете. В такой ситуации можно действовать двумя способами. Первый предполагает выполнение преобразования сетевых адресов, второй же вообще не позволяет внутренним машинам устанавливать какие-либо соединения с машинами из Интернета. Вместо этого устанавливается соединение со специальным внутренним сервером, который ретранслирует это соединение "наружу" (устанавливает отдельное, новое соединение). Благодаря такой схеме внешний сервер соединяется лишь с ретранслирующим сервером, который имеет корректный Интернет-адрес. Фактически, при работе функционируют два отдельных TCP-соединения: |
|
Строка 3: | Строка 5: |
Следующий пункт меню: прокси-сервер. Что такое есть прокси-сервер? Буквально --- ретранслятор. Как и почему его можно применить: есть некая группа компьютеров в сети, которая соединена маршрутизатором с интернетом. Этой группе компьютеров в сети выдан диапазон адресов, например {{{10.0.0.0/8}}}. Как мы знаем, пакеты с такими адресами не маршрутизируются в интернете. Абсолютно бессмысленно выставлять машину с адресом из этого диапазона. Есть два способа проблему решить: преобразовывать адрес машины, или вообще не позволять внутренней машине какие-либо соединения с внешними хостами устанавливать. В последнем случае машина устанавливает соединение с внутренним сервером, а он ретранслирует это соединение (устанавливает отдельное новое соединение) на внешний сервер. Это означает что внешний сервер будет думать, что с ним соединяется ретранслирующий сервер. Вообще говоря, получается такая ситуация, что функционируют два отдельных TCP-соединения. Более того, наиболее простая практика состоит в следующем: внутреннее подключение осуществляется на специальный порт, в ПСПО по умолчанию 3128. То есть, клиент знает, что для соединения с интернет-сервером, ему надо передать на заданный порт специального локального сервера адрес и порт интернет-сервера, с которым клиент желает соединиться. Далее, прокси-сервер подключается, передаёт данные, получает ответ, передаёт его клиенту. При этом, важно понимать, что когда происходит такого рода подключение, удалённая сторона не знает, какой именно внутренний компьютер подключается к ней. | {{attachment:../proxy1.png}} |
Строка 5: | Строка 7: |
##Прозрачный прокси --- не требующий настройки со стороны клиента. В RFC описан как "перехватывающий" (intercepting). | Наиболее простой способ организации такой схемы состоит в следующем: внутреннее подключение осуществляется на специальный порт. В ПСПО (и не только) это по умолчанию 3128. Клиент знает, что для соединения с Интернет-сервером ему надо передать на этот порт локального ретранслирующего сервера адрес и порт Интернет-сервера, с которым он желает соединиться. Прокси-сервер осуществляет подключение, передает данные, получает ответ и транслирует его клиенту. Дальнейшее взаимодействие происходит таким же способом. Заметим, что при этой схеме удаленная сторона не знает, какой именно внутренний компьютер к ней подключается (а может, вообще говоря, и вовсе не знать, что подключается к ней не обычный клиент, а ретранслирующий сервер). |
Строка 7: | Строка 9: |
Иногда это представляет некие неудобства: в некоторых случаях удалённому серверу передаётся локальный адрес того, кому нужно передавать данные в ответ. Именно поэтому существуют анонимизирующие прокси, которые работают на протоколах прикладного уровня, подменяя адреса в нужных пакетах. | Иногда это представляет некие неудобства: в некоторых случаях удалённому серверу передаётся локальный адрес того, кому нужно передавать данные в ответ. Именно поэтому существуют анонимизирующие прокси, которые работают на уровне протоколов прикладного уровня (FTP, IRC), подменяя адреса в нужных пакетах. Говорят также о прозрачных прокси --- не требующих настройки со стороны клиента (в RFC они описаны как intercepting - "перехватывающие"). |
Строка 9: | Строка 11: |
Начнём с простого: настроим браузер на то, чтобы он пользовался нашим сквидом. | ==== Настройка браузера ==== Начнём с простого: настроим браузер на то, чтобы он пользовался нашим прокси-сервером. |
Строка 11: | Строка 14: |
##ожидаются скриншоты | {{attachment:../proxy_settings_configured.png}} |
Строка 13: | Строка 16: |
Это фича, за которую руки надо оторвать (адрес конфигуратора по умолчанию --- не локалхост, а доменное имя данной машины). Если мы настраиваем в броузере прокси на своей машине, надо первым делом запомнить, что надо ходить на 127.0.0.1, или в список исключений адресов, на которые не ходить, добавить себя (или всю локальную сеть). | ## Это фича, за которую руки надо оторвать (адрес конфигуратора по умолчанию --- не локалхост, а доменное имя данной машины). Если мы настраиваем в браузере прокси на своей машине, надо первым делом запомнить, что надо соединяться с конфигуратором по адресу localhost, то есть 127.0.0.1. Альтернативный вариант - в список исключений в браузере (адресов, для которых прокси использовать не надо) добавить адрес локальной машины (или всей локальной сети). |
Строка 15: | Строка 19: |
Принимать соединения --- принимает соединения от любого компьютера. Если есть несклько сетевых инт., то принимаются соед. с любого. Можно указать | ==== Настройка прокси-сервера ==== Выберем в Web-интерфейсе Alterator'a пункт "Прокси-сервер", чтобы настроить прокси-сервер под названием Squid: |
Строка 17: | Строка 22: |
Для добавления клиентов, которые могут проходить через прокси, необходимо добавить машины и подсети в список "Допускать сети". | {{attachment:../alterator_www_squid.png}} |
Строка 19: | Строка 24: |
Добавлять домен --- для случаев, когда адрес машины задан внутри домена, к адресам дописывается заданный в этом поле домен (видимо, для фильтрации соединений внутри локальной сети). | Как видно, здесь можно задать основные настройки прокси-сервера: |
Строка 21: | Строка 26: |
Администратор сервера --- опция cachemgr_passwd --- возможность при аутентификации заданным в поле паролем выполнять некоторые действия (полный список см. squid.conf) с прокси и его кэшем. | * Принимать соединения - если на машине с прокси-сервером есть несколько сетевых интерфейсов, то по умолчанию подключаться к прокси можно с любого из них. Можно, однако, явно задать список адресов прокси-сервера, на которых он принимает соединения. Именно эти адреса могут указывать клиенты в настройках прокси своего браузера. * Допускать сети - список возможных пользователей прокси-сервера. Сюда следует добавить адреса клиентских машин и подсетей. * Добавлять домен - в случае, когда адреса клиентских машин "относительные" (внутри домена), к ним приписывается заданный в этом поле домен. * Администратор сервера - поле, задающее опцию cachemgr_passwd в конфигурационном файле Squid'а. Предъявляющий данный пароль пользователь получает возможность производить с сервером и его кэшем некоторые заранее определенные операции (см. полный список в squid.conf). |
Строка 23: | Строка 31: |
Сетевой трафик. По умолчанию эта служба выключена, чтобы лишний раз не грузить машину. Точно также, как и прокси. | === Служба слежения за сетевым трафиком === Сетевой трафик. По умолчанию эта служба выключена, чтобы не увеличивать нагрузку на компьютер. |
Строка 25: | Строка 34: |
##ожидаются скриншоты | {{attachment:../alterator_www_ulogd.png}} |
Строка 27: | Строка 36: |
Сервер. Настройки web-сервера, на котором крутится конфигуратор. Можно создать самподписанный сертификат. Это удобно --- если сертитфикат самоподписанный и его нельзя проверить, то его можно переподписать, и потом проверить, что это тот самый сертификат. Более того, можно как-то общаться с удостоверительным центром. Речь идёт о том, что можно сгенерировать запрос на подпись, отправить его. | === Управление веб-сервером конфигуратора === В пункте "Web-интерфейс: Сервер" можно задать настройки используемого конфигуратором Web-сервера. Как видно, здесь можно создать "самоподписанный" сертификат с настраиваемыми параметрами. Это может оказаться удобным: если сертификат самоподписанный и не может быть проверен, то его можно переподписать и в дальнейшем проверять, что это тот самый сертификат. Отсюда же можно отправить запрос на подпись сертификата в удостоверительный центр. |
Строка 29: | Строка 39: |
Для того, чтобы завершить тему конфигурации машины через web-морду, остались две темы: сетевой экран и CUPS. | {{attachment:../alterator_www_settings.png}} |
Строка 31: | Строка 41: |
## CUPS в итоге отцепился | === Настройка сетевого экрана === В настройках сетевого экрана можно настраивать блокировку входящего трафика в соответствии с используемым протоколом. По умолчанию пропускается любой протокол, а при внесении каких-либо изменений любой не разрешенный явно протокол блокируется. Разумно, к примеру, разрешать ICMP, HTTP, HTTPS, SSH (это, очевидно, зависит от функций, выполняемых конкретной машиной в сети). Каждый из сетевых интерфейсов конфигурируется отдельно. |
Строка 33: | Строка 44: |
Сетевой экран. По умолчанию ничего не запрещено. И если делаете какие-то настройки, то последним правилом вставляется запретить всё. По умолчанию стоит пропускать ICMP, HTTP, HTTPS, SSH. Это запрет на входящий трафик, а не на исходящий. | {{attachment:../alterator_www_firewall.png}} |
Строка 40: | Строка 51: |
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date || || 15 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, DmitryChistikov || || || |
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date || || 90 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, DmitryChistikov, MaximByshevskiKonopko || || || |
Строка 44: | Строка 56: |
CategoryLectures CategoryPspo CategoryMpgu CategoryUneex | CategoryLectures CategoryPspo CategoryMpgu CategoryUneex |
Web-интерфейс центра управления: продолжение
Proxy
Следующий пункт меню: прокси-сервер. Сам этот термин буквально означает "ретранслятор". Применяются ретрансляторы в следующей ситуации: пусть некоторая группа компьютеров в локальной сети подключена к Интернету через маршрутизатор. В самой сети компьютеры имеют адреса из диапазона, скажем, 10.0.0.0/8. Как известно, пакеты с такими адресами не маршрутизируются в Интернете. В такой ситуации можно действовать двумя способами. Первый предполагает выполнение преобразования сетевых адресов, второй же вообще не позволяет внутренним машинам устанавливать какие-либо соединения с машинами из Интернета. Вместо этого устанавливается соединение со специальным внутренним сервером, который ретранслирует это соединение "наружу" (устанавливает отдельное, новое соединение). Благодаря такой схеме внешний сервер соединяется лишь с ретранслирующим сервером, который имеет корректный Интернет-адрес. Фактически, при работе функционируют два отдельных TCP-соединения:
Наиболее простой способ организации такой схемы состоит в следующем: внутреннее подключение осуществляется на специальный порт. В ПСПО (и не только) это по умолчанию 3128. Клиент знает, что для соединения с Интернет-сервером ему надо передать на этот порт локального ретранслирующего сервера адрес и порт Интернет-сервера, с которым он желает соединиться. Прокси-сервер осуществляет подключение, передает данные, получает ответ и транслирует его клиенту. Дальнейшее взаимодействие происходит таким же способом. Заметим, что при этой схеме удаленная сторона не знает, какой именно внутренний компьютер к ней подключается (а может, вообще говоря, и вовсе не знать, что подключается к ней не обычный клиент, а ретранслирующий сервер).
Иногда это представляет некие неудобства: в некоторых случаях удалённому серверу передаётся локальный адрес того, кому нужно передавать данные в ответ. Именно поэтому существуют анонимизирующие прокси, которые работают на уровне протоколов прикладного уровня (FTP, IRC), подменяя адреса в нужных пакетах. Говорят также о прозрачных прокси --- не требующих настройки со стороны клиента (в RFC они описаны как intercepting - "перехватывающие").
Настройка браузера
Начнём с простого: настроим браузер на то, чтобы он пользовался нашим прокси-сервером.
Если мы настраиваем в браузере прокси на своей машине, надо первым делом запомнить, что надо соединяться с конфигуратором по адресу localhost, то есть 127.0.0.1. Альтернативный вариант - в список исключений в браузере (адресов, для которых прокси использовать не надо) добавить адрес локальной машины (или всей локальной сети).
Настройка прокси-сервера
Выберем в Web-интерфейсе Alterator'a пункт "Прокси-сервер", чтобы настроить прокси-сервер под названием Squid:
Как видно, здесь можно задать основные настройки прокси-сервера:
- Принимать соединения - если на машине с прокси-сервером есть несколько сетевых интерфейсов, то по умолчанию подключаться к прокси можно с любого из них. Можно, однако, явно задать список адресов прокси-сервера, на которых он принимает соединения. Именно эти адреса могут указывать клиенты в настройках прокси своего браузера.
- Допускать сети - список возможных пользователей прокси-сервера. Сюда следует добавить адреса клиентских машин и подсетей.
- Добавлять домен - в случае, когда адреса клиентских машин "относительные" (внутри домена), к ним приписывается заданный в этом поле домен.
- Администратор сервера - поле, задающее опцию cachemgr_passwd в конфигурационном файле Squid'а. Предъявляющий данный пароль пользователь получает возможность производить с сервером и его кэшем некоторые заранее определенные операции (см. полный список в squid.conf).
Служба слежения за сетевым трафиком
Сетевой трафик. По умолчанию эта служба выключена, чтобы не увеличивать нагрузку на компьютер.
Управление веб-сервером конфигуратора
В пункте "Web-интерфейс: Сервер" можно задать настройки используемого конфигуратором Web-сервера. Как видно, здесь можно создать "самоподписанный" сертификат с настраиваемыми параметрами. Это может оказаться удобным: если сертификат самоподписанный и не может быть проверен, то его можно переподписать и в дальнейшем проверять, что это тот самый сертификат. Отсюда же можно отправить запрос на подпись сертификата в удостоверительный центр.
Настройка сетевого экрана
В настройках сетевого экрана можно настраивать блокировку входящего трафика в соответствии с используемым протоколом. По умолчанию пропускается любой протокол, а при внесении каких-либо изменений любой не разрешенный явно протокол блокируется. Разумно, к примеру, разрешать ICMP, HTTP, HTTPS, SSH (это, очевидно, зависит от функций, выполняемых конкретной машиной в сети). Каждый из сетевых интерфейсов конфигурируется отдельно.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
90 |
1 |
1 |
1 |
|
1 |
MaximByshevskiKonopko, DmitryChistikov, MaximByshevskiKonopko |
|
|