Настройка кеширующего интернет-шлюза

Блог им. dreamhunter
Введение
В современном мире крайне важным вопросом является доступ пользователей к сети интернет. Доступ должен быть безопасным, простым и высокоскоростным.

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

На данной схеме пользователи могут работать с интернет только через прокси. Прокси регулирует абсолютно весь трафик. FireWall блокирует весь остальной трафик.

Однако, как правило, с этим возникает много проблем. Даже самые современные прокси-сервера не умеют правильно работать со всеми видами протоколов. Особо возникают проблемы, когда необходимо организовать шифрованные туннели. И тогда приходится открывать доступ к интернет через шлюз. В этих случаях особо встает вопрос о необходимости таких схем. Но, не смотря на неполноценность прокси как фильтра траффика, остаются как минимум две важные функции, которыми он обладает: кеширование и логирование. Это две вещи, ради которых действительно стоит использовать прокси.
Cisco router + squid transparent.
Этот вариант один из наиболее «простых». Простота заключается в том, что маршрутизатор не нуждается в установке, пересборке ядра для включения функций фаирвола. Конечно, это не совсем фаирвол, но access-lists дают неплохой функционал, плюс от маршрутизатора мы можем в дальнейшем получить какие-то дополнительные функции.
В качестве стенда мы будем использовать GNS3.
Шаг 1. Соберем схему из виртуальных машин и маршрутизатора.

В качестве маршрутизатора взят Cisco router 2611 (совет: Лучше пользоваться 7200). Т.к. эта модель обладает только двумя интерфейсами, добавили модуль NM-1E.

Для виртуальных машин воспользовались VirtualBox. Для клиента выбрана WinXP, для прокси — FreeBSD 9.1.

Облако — это наш выход в реальную среду и в реальный интернет.


Шаг 2. Начальная конфигурация.

Запустим собранную схему и подготовим наше оборудование к работе. Начнем с конфигурации Cisco Router. Что бы маршрутизатор получил доступ в интернет:
conf t
interface Ethernet0/0
ip address dhcp
no shutdown
interface Ethernet0/1
description Link to DMZ
ip address 10.1.1.1 255.255.255.0
no shutdown
interface Ethernet1/0
description Link to LAN
ip address 10.1.2.1 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 dhcp
interface Loopback0
ip address 10.1.0.1 255.255.255.255
no shutdown


В моем варианте адрес подключения к интернет получается по DHCP. Вы можете настроить статические адреса.
Далее настроим разрешение имен, DNS, DHCP и NTP серверы. В конце концов если реализовывать схему в реальности, будет глупо не воспользоваться функционалом этой системы.
ip domain lookup
ip name-server 8.8.8.8 8.8.4.4
ip domain name domain.net
ip dns server
ntp logging
ntp master 4
ntp server 93.180.6.3
ntp server 80.90.180.140
clock timezone NOVT 7
ip dhcp pool LAN
network 10.1.2.0 255.255.255.0
default-router 10.1.2.1
dns-server 10.1.2.1
domain-name office.local
ip dhcp pool DMZ
network 10.1.1.0 255.255.255.0
default-router 10.1.1.1
dns-server 10.1.1.1
domain-name office.local


Замечания:

1) Есть вероятность того, что вам понадобится ввести приблизительную дату и время чтобы маршрутизатор мог начать синхронизацию. Это связано с тем что есть предельная разница значений. Если она составляет несколько лет — синхронизация работать не будет.
Вручную можно установить время/дату командой:
clock set 15:22:00 06 july 2013

2) В DMZ лучше не использовать DHCP. Мало того крайне желательно использовать привязку по MAC. Это можно сделать следующим способом:
arp 10.1.1.2 0800.2716.fe92 ARPA
ip dhcp pool proxy-server
host 10.1.1.2 255.255.255.0
default-router 10.1.1.1
dns-server 10.1.1.1
domain-name office.local
client-identifier 0108.0027.16fe.92

Естественно вы должны заранее узнать MAC адрес вашего прокси. Также вероятно вы столкнетесь с тем, что адрес может быть уже занят (по причине того, что вы включили свой прокси и он получил нужный вам адрес). Исправляется с помощью команды:
clear ip dhcp binding 10.1.1.2

Будем считать начальную настройку оконченой. Наши виртуальные машины могут быть теперь настроены на DHCP. Можем проверить промежуточные результаты, запустив виртуальные машины и получив IP адреса. Компьютеры должны видеть друг друга (используем ping), однако доступа к интернет пока быть не должно. Для доступа в сеть интернет необходимо настроить NAT, а точнее PAT т.к. адрес у нас один, а хостов много.

Шаг 3. Настройка трансляции адресов (NAT/PAT).

Для начала определимся с тем, что нам необходимо транслировать. Между пользовательской подсетью и DMZ NAT не требуется. NAT необходим на внешнем интерфейсе. Для этого внесем дополнительные настройки для маршрутизатора:
ip access-list extended NAT-access
permit ip host 10.1.1.2 any
65535 deny   ip any any
ip access-list extended LAN-access
permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
permit udp any any eq bootpc
permit udp any any eq bootps
65535 deny ip any any
interface Ethernet0/0
ip nat outside
interface Ethernet0/1
ip nat inside
interface Ethernet1/0
ip access-group LAN-access in
exit
ip nat inside source list NAT-access interface Ethernet0/0 overload

Теперь наш сервер получил доступ в интернет, а клиент имеет доступ только в DMZ. Пришло время настроить прокси.

Шаг 4. Настройка прокси.

Непосредственно для проксирования можно использовать любой прокси. Но для того чтобы иметь возможность настроить WCCP, нам понадобится Squid. Сначала установим его на подготовленной виртуальной машине с FreeBSD (Для написания статьи использовался Squid 2.7 STABLE9):
cd /usr/ports/www/squid
make install clean

Для нашей схемы нам понадобится установить с функцией WCCPv2. Естественно установщик установит дополнительное ПО для работоспособности. После установки добавим squid в автозапуск:
echo squid_enable="YES" >> /etc/rc.conf

Также необходимо запустить squid -z для того, что бы он создал директории кеша. После этого наш прокси готов к работе. Запускаем командой:
/usr/local/etc/rc.d/squid start

После этого он начинает слушать порт 3128 (по умолчанию).

Настроим в браузере на клиентской машине свойства подключения:

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

Шаг 5. Настройка WCCP

Необходимо, что бы вы понимали, хоть немного, принципы работы WCCP. Потому небольшое отступление:

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

После того, как прокси заявил о своем присутсвии (и при необходимости авторизовался), маршрутизатор начинает перенаправлять веб-запросы на этот сервер. В этом и заключается корернное отличие WCCP от обычного перенаправления. Мало того в WCCP v2 может быть анонсировано несколько прокси, которые будут распределять нагрузку между собой. Из такой схемы можно извлечь очень много плюсов.

Итак подготовим маршрутизатор. К имеющейся конфигурации необходимо добавить следующие параметры:
conf t
access-list 10 permit 10.1.1.2
ip access-list extended proxy-redirect
permit tcp 10.1.2.0 0.0.0.255 any eq www
65535 deny ip any any
ip access-list extended LAN-access
1000 permit tcp any any eq www
ip wccp web-cache redirect-list proxy-redirect group-list 10
interface Ethernet1/0
ip wccp web-cache redirect in
end

Этого должно быть достаточно что бы WCCP сервер (маршрутизатор) начал перенаправлять пакеты. Теперь нам необходимо зарегистрировать наш прокси. Для этого переключаемся на наш прокси и добавляем строчки в файл squid.conf:
http_port 3128 transparent
wccp2_router 10.1.1.1
wccp2_forwarding_method 2
wccp2_return_method 2

Если все хорошо, то после перезапуска squid (/usr/local/etc/rc.d/squid restart), сервер зарегестрируется в WCCP. Проверить можно введя команду в консоли маршутизатора:
show ip wccp web-cache detail

Однако этого мало. Шлюз будет исправно слать пакеты на прокси, однако не будет перенаправления портов. Для перенаправления вам необходимо организовать редирект на сервере.

Добавляем в файл /etc/rc.conf:
gateway_enable="YES"
ipnat_enable="YES"
ipnat_rules="/etc/ipnat.rules"

Создаем файл с правилами для NAT /etc/ipnat.rules:
echo "rdr em0 0.0.0.0/0 port 80 -> 127.0.0.1 port 3128 tcp" >> /etc/ipnat.rules

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

И еще немного:

Эту конфигурацию можно немного модифицировать что бы получить весьма интересную схему:
conf t
ip access-list extended NAT-access
100 permit ip 10.1.2.0 0.0.0.255 any
interface Ethernet1/0
ip nat inside


После этой модификации наши пользователи будут иметь доступ в интернет в любом случае. Даже если прокси выключится. Зато, если потом снова его включить, он автоматически включится и продолжит выполнять свою функцию. Естественно эта схема не очень безопасна. Открывать подобного рода доступы нужно аккуратно. В примере был показан исключительно функционал.
Финальный вариант конфигурации для 7200:
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
no aaa new-model
clock timezone NOVT 7
ip source-route
ip wccp web-cache redirect-list proxy-redirect group-list 10
ip cef
!
!
no ip dhcp use vrf connected
!
ip dhcp pool LAN
   network 10.1.2.0 255.255.255.0
   default-router 10.1.2.1 
   dns-server 10.1.0.1 
   domain-name office.local
!
ip dhcp pool DMZ
   network 10.1.1.0 255.255.255.0
   default-router 10.1.1.1 
   dns-server 10.1.0.1 
   domain-name office.local
!
!
ip domain name domain.net
no ipv6 cef
ntp logging
ntp master 6
ntp server 10.79.226.50
ntp server 10.79.226.51
!
multilink bundle-name authenticated
!
!
interface Loopback0
 ip address 10.1.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address dhcp
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description Link to DMZ
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description Link to LAN
 ip address 10.1.2.1 255.255.255.0
 ip access-group LAN-access in
 ip wccp web-cache redirect in
 ip nat inside
 ip virtual-reassembly
 duplex half
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 dhcp
ip http server
no ip http secure-server
!
!
ip dns server
ip nat inside source list DMZ-access interface FastEthernet0/0 overload
!
ip access-list extended DMZ-access
 permit ip host 10.1.1.2 any
 permit ip 10.1.2.0 0.0.0.255 any
 deny   ip any any
ip access-list extended LAN-access
 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
 permit udp 10.1.2.0 0.0.0.255 any eq bootpc
 permit udp 10.1.2.0 0.0.0.255 any eq bootps
 permit tcp 10.1.2.0 0.0.0.255 any eq www
 deny   ip any any
ip access-list extended proxy-redirect
 permit tcp 10.1.2.0 0.0.0.255 any eq www
 deny   ip any any
!
access-list 10 permit 10.1.1.2
!
!
!
!
!
!
control-plane
!
!
!
mgcp fax t38 ecm
!
!
!
!
gatekeeper
 shutdown
!
!
line con 0
 stopbits 1
line aux 0
 stopbits 1
line vty 0 4
 login
!
end


P.S. Это копия статьи, которая принадлежит мне, потому на источник не ссылаюсь.

0 комментариев

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