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


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


Не секрет, что в большинстве случаев система доступа к интернету осуществляется по стандартной схеме, во главе которой стоит общеизвестный кэширующий прокси-сервер squid. На сегодняшний день существует немало альтернатив (взять хотя бы тот же OOPS), имеющих существенные улучшения. Тем не менее, насколько мне известно, на счету squid по-прежнему львиная доля практических применений. И наш выбор тоже остановился на нем.


Следует отметить, что для просмотра веб-страниц вовсе не обязательно применять кэширующие сервера. Для этого достаточно воспользоваться простым шлюзом, любым узлом, способным выполнять роль маршрутизатора. К интерфейсу, "смотрящему" в интернет, добавляем NAT — и получаем вполне рабочую систему. Однако в таком решении масса недостатков.


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


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


Теперь, когда мы пришли к выводу о необходимости использования кэширования вообще и squid в частности, рассмотрим практическую сторону работы связки "клиент — сервер". В качестве клиентского будет выступать любое приложение, работающее на машине пользователя и нуждающееся в доступ к глобальной сети. С сервером и того проще: это то же самое приложение, работающее, как правило, на отдельной машине в локальной сети и "слушающее" определенный порт на локальном интерфейсе. Очевидно, что для работы клиентского приложения необходимо, чтобы оно знало, куда следует обращаться для получения доступа в интернет (IP-адрес и порт сервера) — см. рис. 1.

 

 

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


Дополнительно приложения, которые могут работать через прокси-сервер, необходимо обязательно отправлять на него. В основном это касается веб-браузеров. В большой сети для них следует жестко прописывать адрес и порт прокси-сервера, что, в принципе, уже неудобно, но еще терпимо. Для односегментной же сети (подразумеваем небольшую организацию) сделать так, чтобы и волки были сыты, и овцы целы, и пастух не пострадал, можно при помощи способа, известного как transparent proxy. Суть его в том, что пользователь даже не догадывается, что использует прокси-сервер. Всю работу делает за него пакетный фильтр (тот же iptables в Linux). Пакет, в момент его поступления на вход, анализируется — чаще всего по номеру порта, к которому обращается,— после чего принимается решение, пускать его напрямую или же через кэш (рис. 2).

 


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


Пришло время подробнее осветить проблемы, с которыми мне пришлось столкнуться при построении и эксплуатации системы интернет-доступа в большой многосегментной сети.


Не мудрствуя лукаво на Linux-сервере установили squid. От системы доступа на основе IP- или MAC-адресов отказались сразу. Сеть большая, вдобавок построенная на основе DHCP, плюс местные "кулхацкеры" владеют секретной технологией подмены адресов. Поэтому авторизация строилась на основе "имя-пароль". Прямой доступ (пока) трогать не будем — та же ICQ с грехом пополам, но работает и без него. Имя и пароль, кстати, брались из windows-домена и на всякий пожарный сохранялись локально — на случай "падения" самой распространенной системы.


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


Оказалось, да — есть в squid педаль, позволяющая одновременно работать только одному пользователю, то есть одной связке имя-пароль в единицу времени. Однако реализовано это не слишком гибко. Проблема в том, что пользователь получал доступ с другой машины не сразу, а через определенный промежуток времени по окончанию работы на предыдущей машине. К тому же и с ICQ пришлось помучиться: то работает, то нет.


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


В процессе поисках решения и генерации различных идей выбор пал на протокол PPP и его вариации PPPoE и PPTP.


Первое, что приходит в голову большинству людей при упоминании протокола PPP, это доступ в интернет по телефонной линии, то бишь dial-up . Но на этом применение PPP не заканчивается. Здесь стоит остановиться и немного рассказать о таком процессе, как инкапсуляция. Под инкапсуляцией, применительно к сетям, понимают внедрение пакета данных одного протокола в тело другого протокола. Так поступают при организации туннелей внутри общедоступных сетей, при связывании разнопротокольных сетей и т.д. В большинстве своем инкапсуляцию применяют для организации канала типа "точка — точка".


В нашем случае применение PPP поверх общей среды Ethernet предоставляет в наше распоряжение все возможности, используемые провайдерскими конторами для организации и учета доступа в интернете по dial’up-линии. Это и аутентификация pap, chap. И невозможность подмены IP-адресов. И точный учет рабочего времени.


Структурная схема будущей системы была такой. Пользователь не получит доступ к интернету, пока не организует канал "точка — точка" внутри локальной сети с сервером и не получит выданный им IP-адрес из "левого" пула адресов, никак не пересекающихся с адресами в локальной сети. Все это произойдет только после аутентификации по протоколу pap или chap на сервере доступа.


Cервер доступа, в свою очередь, использует сервер RADIUS или TACACS . В этой схеме очень просто реализуется ограничение на количество постоянных соединений пользователя. Причем сразу после разрыва соединения мы можем воспользоваться другим клиентским местом — и все будет ok. Различие в реализации серверов доступа PPPoE и PPTP (применительно к организации интернет-доступа) заключается в том, что для организации доступа PPPoE не требует, чтобы клиентам были выданы какие либо IP-адреса,— для нахождения сервера доступа используются широковещательные рассылки. Такой подход имеет как плюсы, так и минусы. Плюс в том, что в случае организации интернет-доступа в жилом доме или в любом другом случае, когда нельзя всем навязывать жесткие адреса, для PPPoE проблем не будет. Минус в том, что необходима односегментная сеть — без промежуточных маршрутизаторов (рис. 3).

 


По умолчанию маршрутизаторы не пропускают широковещательные пакеты. В нашем случае — в большой, разветвленной многосегментной сети — это не пройдет. К стати, клиент PPPoE уже встроен в Windows, так что нет необходимости в устанавке каких-то "левых" программ.


А вот использование PPTP подразумевает наличие у клиента IP-адреса и возможность связи с PPTP серверов в сети. Говоря проще, должна работать маршрутизация до PPTP-сервера. Далее, в принципе, все аналогично. Клиент устанавливает фиксированное соединение с PPTP-сервером, получает IP-адрес, организуется туннель внутри локальной сети с сервером. PPTP-клиент в Windows существует испокон веков (рис. 4).

 


Помимо уже указанных, такая схема дает нам следующие удобства. Приложения имеют прямой доступ в интернет, естественно с участием NAT, без каких-либо прописок на стороне клиента, адреса прокси-сервера и т.д. В такой схеме прокси будет задействован как transparent. Приложения, идущие на 80-й порт, отправляются на squid, остальные — "прямой наводкой". Кроме того, мы использовали ограничение доступа через squid на основе IP-адресов, выдаваемых клиентам. Так что никакой дополнительной аутентификации пользователь на такой схеме замечал. Запрет на доступ к мультимедиа-информации в дневное время и т.д.


Для работы подобной схемы необходимо точно знать, какие пулы адресов назначаются конечным пользователям. Это можно реализовать как через RADIUS, так и на сервере доступа. В нашем случае это было сделано через RADIUS. Поскольку контора была богатая, то в качестве PPTP-сервера выступал один из серверов доступа производства Сisco. На Cisco были прописаны пулы выдаваемых адресов для каждой группы пользователей. Через RADIUS пулы назначались пользователям для конкретного соответствия. В squid прописали access-листы по IP-адресам.


В данной схеме удалось обойти проблему "падения" прокси-сервера. Как было сказано выше, при неполадках в работе прокси-сервера, задействованного по transparent-схеме, многие приложения перестанут работать. Чтобы этого не случилось, необходим механизм автоматического определения состояния прокси-сервера. В случае неправильной работы сервера пересылка запросов на прокси-сервер должна отключаться — запросы должны идти напрямую. Именно для этого существует протокол wccp (
www.cisco.com/en/US/tech/tk122/tk717/tsd_technology_support_protocol_home.html) — оригинальное изобретение компании Сisco. Его реализация включена и в прокси-сервер squid (рис. 5).

 

 

Поэтому использование сервера доступа Сisco в качестве сервера PPTP или PPPoE позволяет реализовать чрезвычайно надежную схему. Поскольку аппаратные решения a priory надежнее софтверных, то получилась практически неубиваемая схема. Понятно, что далеко не каждая фирма сможет приобрести железку от Сisco, однако все описанное выше будет отлично работать и на обычном сервере (за исключением, естественно, wccp). Если вы в состоянии купить access-сервер от Cisco, возможно вы изыщете возможность приобрести и аппаратный кэш-сервер этой компании.

 

Вот вкратце то, что названо "универсальной альтернативой". В статье нет описаний конкретных программных реализаций. Нет сравнения различных программных решений. Все это тянет еще не на одну статью.

2005.07.29
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".