Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Мобильные клиенты WiFi через прокси Squid

    Russian
    3
    19
    11773
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sundoom last edited by

      Добрый день.
      Возникла очередная загвозка. Задача: необходимо пустить мобильных юзеров по WiFI прозрачно через прокси сервер сквид (версия 2.7), не прописывая параметры прокси сервера в настройки браузера. Причем сквид поднят с авторизацией по kerberos для локальных сетей и вполне достойно работает.
      Теперь распишу, что было сделано.
      На PFS добавлен интерфейс WIFI_WAN (222.222.222.0/24 сеть), на котором крутится WiFi сеть. Прописаны шлюз, маршрут, правила файрвола и nat, шейпер для этого интерфейса. Все работает как надо. Но появилась необходимость наблюдения и учета Web-трафика у мобильных пользователей, соотвественно, нужно пустить определенный трафик через сквид прозрачно без аутентификации. Для этого в Firewall: NAT: Port Forward сделал проброс 80 порта на интерфейсе WIFI_WAN на локальный адрес и порт сквида (172.16.0.132:81), автоматом создалось правило файрвола для интерфейса WIFI_WAN. Включил на этом правиле лог. С мобильного клиента по WIFI захожу, например, на яндекс и вываливается ошибка:


      ОШИБКА
      Запрошенный URL не может быть доставлен.

      Во время обработки запроса:
      GET /?clid=46143 HTTP/1.1
      User-Agent: Opera/9.80 (S60; SymbOS; Opera Mobi/SYB-1204232254; U; ru) Presto/2.10.254 Version/12.00
      Host: www.yandex.ru
      Accept: text/html, application/xml;q=0.9, application/xhtml+xml, multipart/mixed, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, /;q=0.1
      Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
      Accept-Encoding: gzip, deflate
      Cookie: yandexuid=1394582561316531546
      Connection: Keep-Alive
      X-EBO-UA: BID=1.3.0, BCReq=69C76015BAD50D3543F943ABAED370FE

      Произошла следующая ошибка:
      Неверный запрос.

      Некоторые аспекты HTTP запроса неправильны. Возможные проблемы:
      Отсутствует либо неизвестен метод запроса (GET, POST)
      Отсутствует URL
      Отсутствует HTTP идентификатор (HTTP/1.0)
      Запрос слишком велик
      Не указан Content-Length для запросов POST или PUT
      Недопустимый символ в имени сервера; подчеркивания недопустимы

      Generated Wed, 30 May 2012 03:11:29 GMT by pfsense (squid/2.7.STABLE9)


      В логах файрвола видно, что проброс сработал и файрвол пустил это соединение.

      Выкладываю конфиг сквида: В фалике unrestricted_hosts.acl прописан адрес WiFi шлюза, через который ходят мобильные юзеры 222.222.222.2.


      http_port 172.16.0.132:81
      icp_port 0

      pid_filename /var/run/squid.pid
      cache_effective_user proxy
      cache_effective_group proxy
      error_directory /usr/local/etc/squid/errors/Russian-1251
      icon_directory /usr/local/etc/squid/icons
      visible_hostname pfsense
      access_log /var/squid/logs/access.log
      cache_log /var/squid/logs/cache.log
      cache_store_log none
      logfile_rotate 30
      shutdown_lifetime 3 seconds

      acl localnet src 172.16.0.0/255.255.255.0
      acl localnet src 172.16.1.0/255.255.255.0
      acl localnet src 192.168.0.0/255.255.255.0
      acl localnet src 192.168.25.0/255.255.255.0
      acl localnet src 222.222.222.0/255.255.255.0

      uri_whitespace strip

      cache_mem 100 MB
      maximum_object_size_in_memory 32 KB
      memory_replacement_policy heap GDSF
      cache_replacement_policy heap LFUDA
      cache_dir ufs /var/squid/cache 500 16 256
      minimum_object_size 0 KB
      maximum_object_size 4 KB
      offline_mode off
      cache_swap_low 90
      cache_swap_high 95

      acl all src 0/0
      acl localhost src 127.0.0.1/255.255.255.255
      acl webserver src 172.16.0.132/255.255.255.255
      acl safeports port 20 21 70 80 210 280 443 488 563 591 631 777 901 3128 1025-65535
      acl sslports port 20 21 443 563
      acl manager proto cache_object
      acl purge method PURGE
      acl connect method CONNECT                                                                                                                    
      acl dynamic urlpath_regex cgi-bin ?
      acl blacklist dstdom_regex -i "/var/squid/acl/blacklist.acl"
      acl whitelist dstdom_regex -i "/var/squid/acl/whitelist.acl"
      cache deny dynamic

      acl allow_hosts src "/var/squid/acl/unrestricted_hosts.acl"
      http_access allow allow_hosts

      acl FTPclient proto FTP
      acl FTP_port port 60000-61000
      http_access allow FTPclient
      http_access allow CONNECT FTP_port

      http_access allow manager webserver
      http_access deny webserver
      http_access deny manager
      http_access allow purge localhost
      http_access deny purge
      http_access deny !safeports
      http_access deny CONNECT !sslports
      http_access allow localhost
      http_access allow whitelist
      tcp_outgoing_address 127.0.0.1
      auth_param negotiate program /usr/local/libexec/squid/squid_kerb_auth -d -s HTTP/pfsense.green.local
      auth_param negotiate children 30
      auth_param negotiate keep_alive on
      acl auth_users proxy_auth REQUIRED  
      external_acl_type domain_users %LOGIN /usr/local/libexec/squid/squid_ldap_group -R -b "dc=green,dc=local" -f "(&(sAMAccountName=%v)(memberOf=CN=%a,CN=Builtin,DC=green,DC=local))" -D el2@green.local -w 16312352 -K go-srv

      acl Avtomat external domain_users Internet-Avtomat
      acl InetUsers external domain_users Internet-Users
      acl OSB external domain_users Internet-OSB
      acl Unlimit external domain_users Internet-Unlimit
      acl Mail external domain_users Internet-Mail

      request_body_max_size 0 KB
      reply_body_max_size 0 deny all

      delay_pools 1
      delay_class 1 2
      delay_parameters 1 250000/250000 100000/100000
      delay_access 1 allow InetUsers
      delay_access 1 allow OSB
      delay_access 1 allow Mail
      delay_access 1 allow Avtomat
      delay_access 1 allow Unlimit

      http_access deny Avtomat blacklist
      http_access allow Avtomat
      http_access deny InetUsers blacklist
      http_access allow InetUsers
      http_access deny OSB blacklist
      http_access allow OSB
      http_access deny Unlimit blacklist
      http_access allow Unlimit
      http_access deny MoneyOrders blacklist
      http_access allow MoneyOrders
      http_access deny Mail blacklist
      http_access allow Mail
      http_access deny !Avtomat
      http_access deny localnet
      http_access deny all


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

      1 Reply Last reply Reply Quote 0
      • werter
        werter last edited by

        Если доступ беспроводных клиентов к локальной сети (LAN ) не ограничивается, то смею предложить давать подключающимся ви-фи клиентам адреса из локальной сети (по dchp), переведя сам беспроводной интерфейс в режим точки доступа (Access point) , т.е. этакого свитча-без-проводов. И тогда в Сеть "прозрачно" через сквид они точно будут бегать.

        Имхо, это как вариант :)

        P.s. А telnet на 172.16.0.132 и 81 порт с мобильных клиентов идет? А если так попробовать ?


        1 Reply Last reply Reply Quote 0
        • S
          sundoom last edited by

          У меня так не получится. Дело в том, что вай-фай клиенты сидят за вай-фай роутером в отдельной сети (10.10.10.0/24) и вай-фай роутер по DHCP раздает им ip адреса. А уже от вай-фай роутера от его WAN интерфейса (222.222.222.2) прокинут шнурок к моему PFS, на котором заведен отдельный интерфейс WIFI_WAN (222.222.222.1). Все мобильные клиенты ходят в инет и другие локальные сети через шлюз 222.222.222.2.

          Насчет telnet попробую проверить, только надо найти телнет-клиент на свой смартфон.

          1 Reply Last reply Reply Quote 0
          • werter
            werter last edited by

            @sundoom:

            У меня так не получится. Дело в том, что вай-фай клиенты сидят за вай-фай роутером в отдельной сети (10.10.10.0/24) и вай-фай роутер по DHCP раздает им ip адреса. А уже от вай-фай роутера от его WAN интерфейса (222.222.222.2) прокинут шнурок к моему PFS, на котором заведен отдельный интерфейс WIFI_WAN (222.222.222.1). Все мобильные клиенты ходят в инет и другие локальные сети через шлюз 222.222.222.2.

            Насчет telnet попробую проверить, только надо найти телнет-клиент на свой смартфон.

            Во как закручено  ??? Может стоит по-другому с роутером поступить и это не единственное решение вашей задачи?
            Схему, пож-та, для наглядности .

            P.s. Как вариант, роутер перевести в режим ТД . Из него (ВАН-ифейс) кабель до pf и на ифейсе, в к-ый входит шнурок от роутера, поднять DHCP с раздачей свободных адресов как у подсети ЛАН. У меня так роутер от д-линка (дир-615) работает и уже довольно давно. Или попробовать объединить WAN_WIFI и LAN в бридж.

            P.s.s. У вас на WIFI_WAN -  белый IP (222.222.222.x)? Вы из Китая - http://bgp.he.net/ip/222.222.222.1#_ipinfo ? Если нет - смените адрес на что-то более вменяемое для локальных (серых) сетей.

            1 Reply Last reply Reply Quote 0
            • S
              sundoom last edited by

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

              По схеме видно, что вай-фай клиенты идут через вай-фай роутер и пфсенс в инет (проходят через 2 роутера). Соответственно, ip вай-фай клиентов подставляется ip адресом вай-фай роутера. Но мне нужно, чтобы веб-трафик от вай-фай роутера шел через сквид. Пока не получается…

              Кстати, PFSense поднят на виртуалке, если это что-то меняет.


              1 Reply Last reply Reply Quote 0
              • N
                nomeron last edited by

                А wifi router на схеме это точно роутер (NAT отключен) ?

                1 Reply Last reply Reply Quote 0
                • werter
                  werter last edited by

                  А в настройках прокси во вкладке Proxy server: Access control разрешена подсеть 222.222.222.х ?

                  1 Reply Last reply Reply Quote 0
                  • S
                    sundoom last edited by

                    @nomeron:

                    А wifi router на схеме это точно роутер (NAT отключен) ?

                    ТОчно роутер. NAT включен. Я вижу только общий трафик от роутера, т.е. его IP адрес.

                    @werter:

                    А в настройках прокси во вкладке Proxy server: Access control разрешена подсеть 222.222.222.х ?

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

                    1 Reply Last reply Reply Quote 0
                    • N
                      nomeron last edited by

                      ТОчно роутер. NAT включен. Я вижу только общий трафик от роутера, т.е. его IP адрес.

                      Тогда как я понимаю
                      Исходное значения
                      10.10.10.1:рандом 1–> internet addr:80
                      NAT на wifi
                      222.222.222.2:рандом 2 --> internet addr:80

                      Ваше правило NAT
                      src xxx:80 -->  dst 172.16.0.132:81
                      тогда под него ничего не подпадает

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

                      1 Reply Last reply Reply Quote 0
                      • werter
                        werter last edited by

                        Да,  и учет трафика , если получится запустить, будет ОБЩИМ , т.к. весь будет натиться на 222.222.222.1.
                        Попробуйте назначить в Virtual IP интерфейсу WIFI_WAN дополнительно незанятый адрес из подсети 172.16.0.0\24. В правилах NAT-а создать новое правило - натить ви-фи клиентов на этот адрес и поместить его в самый верх.

                        Но, ИМХО, повторяю, самым простым и приемлемым вариантом для вас был бы перевод ви-фи роутера в режим обычной ТД и раздача (получается прозрачно) адресов ви-фи клиентам по dhcp pf-ом автоматом. И не надо будет делать двойной (!) NAT.

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

                        1 Reply Last reply Reply Quote 0
                        • S
                          sundoom last edited by

                          @nomeron:

                          Ваше правило NAT
                          src xxx:80 –>  dst 172.16.0.132:81
                          тогда под него ничего не подпадает

                          По логике да, но почему при применении этого правила у меня и вываливается вышеописанная ошибка? Получается, что данное правило NAT влияет на дальнейшую маршрутизацию пакетов.
                          Сразу встречный вопрос может ли squid работать одновременно в 2х режимах: прозрачном и в режиме аутентификации? Где-то в инете встречал, что не может. Может заблуждаюсь?

                          @werter:

                          Да,  и учет трафика , если получится запустить, будет ОБЩИМ , т.к. весь будет натиться на 222.222.222.1.

                          Это я знаю. Мне бы пока так - общий трафик учитывать.

                          @werter:

                          Попробуйте назначить в Virtual IP интерфейсу WIFI_WAN дополнительно незанятый адрес из подсети 172.16.0.0\24. В правилах NAT-а создать новое правило - натить ви-фи клиентов на этот адрес и поместить его в самый верх.

                          Попробую.

                          @werter:

                          Но, ИМХО, повторяю, самым простым и приемлемым вариантом для вас был бы перевод ви-фи роутера в режим обычной ТД и раздача (получается прозрачно) адресов ви-фи клиентам по dhcp pf-ом автоматом. И не надо будет делать двойной (!) NAT.

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

                          НАсчет ТД - это понятно. А вот насчет того, чтоб сделать более правильно - не так у нас все просто. Есть ряд причин, в том числе амбициозного характера вышестоящих лиц.

                          1 Reply Last reply Reply Quote 0
                          • N
                            nomeron last edited by

                            По логике да, но почему при применении этого правила у меня и вываливается вышеописанная ошибка? Получается, что данное правило NAT влияет на дальнейшую маршрутизацию пакетов.
                            Сразу встречный вопрос может ли squid работать одновременно в 2х режимах: прозрачном и в режиме аутентификации? Где-то в инете встречал, что не может. Может заблуждаюсь?

                            Очень похоже, что ваш запрос проходит через нат на самом пф минуя сквид.
                            Потом, поскольку правилу удовлетворяет ответ из интернета (т.е. сама страница яндекса с порта 80) она отправляется на порт сквида.
                            Структура пакета в таком случае ошибочная, но часть информации видимо сквид понимает. И в пакете есть правильный обратный адрес (который отдал нат) на который сквид и отдает ошибку.

                            1 Reply Last reply Reply Quote 0
                            • werter
                              werter last edited by

                              НАсчет ТД - это понятно. А вот насчет того, чтоб сделать более правильно - не так у нас все просто. Есть ряд причин, в том числе амбициозного характера вышестоящих лиц

                              В такой ситуации я все делаю втихую. Задача была поставлена - задача решена, остальное - ненужные ньюансы. Да и начальство особо не вникает - то ли не интересует их это, то ли квалификации (иногда) не хватает.

                              1 Reply Last reply Reply Quote 0
                              • N
                                nomeron last edited by

                                В такой ситуации я все делаю втихую. Задача была поставлена - задача решена, остальное - ненужные ньюансы. Да и начальство особо не вникает - то ли не интересует их это, то ли квалификации (иногда) не хватает.

                                Так и стоит делать. Хотя наверно решающий показатель надежность работы\время обслуживания.
                                Если есть куча времени ковырять пф и потом бегать и разбираться, где что отвалилось, то городите свою систему.
                                Я вначале в пф сомневался, но уже 3 месяца четыре точки доступа раздают wifi (в режиме NAT+лимитер). Это параллельно с двумя рабочими подсетями.
                                Только народ жалуется, что уж больно точно скорость обрезается. Сквид бы наверно немного ускорил загрузку страниц.

                                1 Reply Last reply Reply Quote 0
                                • S
                                  sundoom last edited by

                                  Короче, перевел, wifi роутеры в режим AP, в PF настроил DHCP, ip клиентам выдаются, настроил правила, NAT - интернет работает. Попытался завернуть все это через прокси. Вылазит та же самая ошибка, что и в шапке темы. Делал так:
                                  Wifi сеть 10.0.0.0/24, IP на WIFI_WAN 10.0.0.1
                                  В Nat создал такое правило:
                                    If          Proto   Src. addr Src. ports Dest. addr Dest. ports NAT IP       NAT Ports
                                  WIFI_WAN TCP         *     *                *            80 (HTTP) 10.0.0.1 81

                                  В прокси добавил такие строчки:
                                  http_port 10.0.0.1:81
                                  acl WIFI-net src 10.0.0.0/255.255.255.0
                                  http_access allow WIFI-net

                                  Т.к. на LAN интерфейсе сквид работает не в прозрачном режиме с аутентификацией по kerberos и авторизацией по ldap, то acl WIFI-net я прописал до авторизации. Если включить прозрачный режим на интерфейсе 10.0.0.1, то вай-фай трафик идет через сквид, но сквид не может работать в 2х режимах одновременно и в логах ссыпятся ошибки:
                                  aclAuthenticated: authentication not applicable on transparently intercepted requests

                                  Помогите, плиз, разрулить ситуацию правильно.

                                  P.S. ПФсенс у меня работает в кластере, т.е. поднят CARP и чтобы сквид мог работать в кластере были добвлены такие правила NAT для каждого ПФсенса:
                                  If        Proto   Src. addr Src. ports Dest. addr Dest. ports NAT IP       NAT Ports
                                  LAN TCP          *      *           172.16.0.250      81         172.16.0.132 81
                                  LAN TCP          *      *           172.16.0.250      81           172.16.0.133 81

                                  где 172.16.0.250 - CARP IP для LAN
                                  172.16.0.132 - IP address PFSense1
                                  172.16.0.133 - IP address PFSense2

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    nomeron last edited by

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

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

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      sundoom last edited by

                                      Короче сделал так, хотя это неправильно, но работает. Добавил в конфиг сквида след. строчки и пустил вай-фай клиентов до аутентификации:

                                      http_port 10.0.0.1:81
                                      acl WIFI-net src 10.0.0.0/255.255.255.0
                                      http_access allow WIFI-net

                                      И добавил правило NAT (завернул веб трафик с вай-фай на сквид).

                                      WIFI TCP 10.0.0.0/24 * * 80 (HTTP) 10.0.0.1 81

                                      Работает в других сетях аутентификация и авторизация как и прежде, а сетку WIFI пускает прозрачно. Правда в логах cache.log  сыпятся такие ошибки:
                                      aclAuthenticated: authentication not applicable on transparently intercepted requests

                                      Теперь вопрос как сделать так, чтобы в логах не появлалась эта ошибка, т.е. отключить логирование для таких типов ошибок, чтоб не засорять лог?

                                      1 Reply Last reply Reply Quote 0
                                      • N
                                        nomeron last edited by

                                        Поделитесь опытом
                                        С этим правилом

                                        WIFI    TCP    10.0.0.0/24    *    *    80 (HTTP)    10.0.0.1    81

                                        остается доступ из wifi к веб интерфейсу пф.
                                        Не пробовали еще такое правило
                                        WIFI    TCP    10.0.0.0/24    *    *    443 (HTTPs)    10.0.0.1    81
                                        оно ведь тоже многим нужно

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          sundoom last edited by

                                          По 443 порту в прозрачном режиме сквид не может работать, как и с ftp. Такое правило ради интереса я пробовал - не работает.
                                          Трафик по 443 порту пришлось пустить в обход сквида. А правилами файрвола я закрыл доступ из вай-фай к локальной сети за исключением некоторых адресов.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post