|
Размер: 7806
Комментарий:
|
← Версия 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(? --- см. /etc/services). То есть, клиент знает, что его не пускают в сеть, поэтому подключается к серверу по специальному протоколу, говорит имя хоста и порт и просит гнать данные дальше (TODO). Сервер дальше подключается, передаёт данные, получает ответ, передаёт его клиенту. При этом, важно понимать, что когда происходит такого рода подключение, удалённая сторона не знает, какой именн компьютер подключается к ней. | {{attachment:../proxy1.png}} |
| Строка 5: | Строка 7: |
| ##Прозрачный прокси --- когда он подкл. к какому-то серверу на 80 порт, на самом деле, он подключается к прокси, который уже форвардит соединение. Следовательно, это не требует настр. браузера и созд. множество проблем. | Наиболее простой способ организации такой схемы состоит в следующем: внутреннее подключение осуществляется на специальный порт. В ПСПО (и не только) это по умолчанию 3128. Клиент знает, что для соединения с Интернет-сервером ему надо передать на этот порт локального ретранслирующего сервера адрес и порт Интернет-сервера, с которым он желает соединиться. Прокси-сервер осуществляет подключение, передает данные, получает ответ и транслирует его клиенту. Дальнейшее взаимодействие происходит таким же способом. Заметим, что при этой схеме удаленная сторона не знает, какой именно внутренний компьютер к ней подключается (а может, вообще говоря, и вовсе не знать, что подключается к ней не обычный клиент, а ретранслирующий сервер). |
| Строка 7: | Строка 9: |
| Иногда это представляет некие неудобства: некому протоколу прикладного уровня передаётся адрес, например, URL, то удалённому серверу передаётся локальный адрес того, кому нужно вернуть данные. Именно поэтому существуют анонимизирующие прокси, которые уже работают на протоколах прикладного уровня, подменяя адреса в нужных пакетах. | Иногда это представляет некие неудобства: в некоторых случаях удалённому серверу передаётся локальный адрес того, кому нужно передавать данные в ответ. Именно поэтому существуют анонимизирующие прокси, которые работают на уровне протоколов прикладного уровня (FTP, IRC), подменяя адреса в нужных пакетах. Говорят также о прозрачных прокси --- не требующих настройки со стороны клиента (в RFC они описаны как intercepting - "перехватывающие"). |
| Строка 9: | Строка 11: |
| Начнём с простого: настроим броузер на то, чтобы он пользовался нашим сквидом. | ==== Настройка браузера ==== Начнём с простого: настроим браузер на то, чтобы он пользовался нашим прокси-сервером. |
| Строка 11: | Строка 14: |
| Это фича, за которую руки надо оторвать. Если мы настраиваем в броузере прокси на своей машине, надо первым делом надо запомнить, что первым делом надо ходить на 127.0.0.1, или добавить в список исключений адресов, на которые не ходить, добавить себя (или всю локальную сеть). | {{attachment:../proxy_settings_configured.png}} |
| Строка 13: | Строка 16: |
| Принимать соединения --- принимает соединения от любого компьютера. Если есть несклько сетевых инт., то принимаются соед. с любого. Можно указать | ## Это фича, за которую руки надо оторвать (адрес конфигуратора по умолчанию --- не локалхост, а доменное имя данной машины). Если мы настраиваем в браузере прокси на своей машине, надо первым делом запомнить, что надо соединяться с конфигуратором по адресу localhost, то есть 127.0.0.1. Альтернативный вариант - в список исключений в браузере (адресов, для которых прокси использовать не надо) добавить адрес локальной машины (или всей локальной сети). |
| Строка 15: | Строка 19: |
| Для добавления клиентов, которые могут проходить через прокси, необходимо добавить машины и подсети в список "Допускать сети". | ==== Настройка прокси-сервера ==== Выберем в Web-интерфейсе Alterator'a пункт "Прокси-сервер", чтобы настроить прокси-сервер под названием Squid: |
| Строка 17: | Строка 22: |
| Добавлять домен --- если имя локальное, то добавлять этот домен. | {{attachment:../alterator_www_squid.png}} |
| Строка 19: | Строка 24: |
| ##Добавить описание, что тут происходит | Как видно, здесь можно задать основные настройки прокси-сервера: |
| Строка 21: | Строка 26: |
| Администратор сервера ---- cachemgr_passwd. | * Принимать соединения - если на машине с прокси-сервером есть несколько сетевых интерфейсов, то по умолчанию подключаться к прокси можно с любого из них. Можно, однако, явно задать список адресов прокси-сервера, на которых он принимает соединения. Именно эти адреса могут указывать клиенты в настройках прокси своего браузера. * Допускать сети - список возможных пользователей прокси-сервера. Сюда следует добавить адреса клиентских машин и подсетей. * Добавлять домен - в случае, когда адреса клиентских машин "относительные" (внутри домена), к ним приписывается заданный в этом поле домен. * Администратор сервера - поле, задающее опцию cachemgr_passwd в конфигурационном файле Squid'а. Предъявляющий данный пароль пользователь получает возможность производить с сервером и его кэшем некоторые заранее определенные операции (см. полный список в squid.conf). |
| Строка 23: | Строка 31: |
| Сетевой трафик. По умолчанию эта служба выключена, чтобы лишний раз не грузить машину. Точно также, как и прокси. | === Служба слежения за сетевым трафиком === Сетевой трафик. По умолчанию эта служба выключена, чтобы не увеличивать нагрузку на компьютер. |
| Строка 25: | Строка 34: |
| Сервер. Настройки web-сервера, на котором крутится конфигуратор. Можно создать самподписанный сертификат. Это удобно, если сертитфикат самоподписанный и его нельзя проверить, то его можно переподписать, и потом всё равно проверить, что подписали его вы. Более того, вы можете как-то общаться с удостоверительным центром, но речь идёт о том, что вы можете сгенерировать запрос на подпись, отправить его. | {{attachment:../alterator_www_ulogd.png}} |
| Строка 27: | Строка 36: |
| Для того, чтобы завершить тему конфигурации машины через web-морду, остались две темы: сетевой экран и CUPS. | === Управление веб-сервером конфигуратора === В пункте "Web-интерфейс: Сервер" можно задать настройки используемого конфигуратором Web-сервера. Как видно, здесь можно создать "самоподписанный" сертификат с настраиваемыми параметрами. Это может оказаться удобным: если сертификат самоподписанный и не может быть проверен, то его можно переподписать и в дальнейшем проверять, что это тот самый сертификат. Отсюда же можно отправить запрос на подпись сертификата в удостоверительный центр. |
| Строка 29: | Строка 39: |
| ## CUPS в итоге отцепился | {{attachment:../alterator_www_settings.png}} |
| Строка 31: | Строка 41: |
| Сетевой экран. По умолчанию ничего не запрещено. И если делаете какие-то настройки, то последним правилом вставляется запретить всё. По умолчанию стоит пропускать ICMP, HTTP, HTTPS, SSH. Это запрет на входящий трафик, а не на исходящий. | === Настройка сетевого экрана === В настройках сетевого экрана можно настраивать блокировку входящего трафика в соответствии с используемым протоколом. По умолчанию пропускается любой протокол, а при внесении каких-либо изменений любой не разрешенный явно протокол блокируется. Разумно, к примеру, разрешать ICMP, HTTP, HTTPS, SSH (это, очевидно, зависит от функций, выполняемых конкретной машиной в сети). Каждый из сетевых интерфейсов конфигурируется отдельно. {{attachment:../alterator_www_firewall.png}} |
| Строка 38: | Строка 51: |
| || Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date || || 9 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, DmitryChistikov || || || |
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date || || 90 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, DmitryChistikov, MaximByshevskiKonopko || || || |
| Строка 41: | Строка 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 |
|
|