Назад | Перейти на главную страницу

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

Я пытаюсь создать Открыть лабораторию устройств.

В этом вопросе основное внимание уделяется сетевой маршрутизации и внедрению кода в ответы на запросы, сделанные тестовыми устройствами.

Я хочу, чтобы люди могли приходить со своими ноутбуками и тестировать их как можно безболезненно. Я хочу, чтобы разработчики могли:

Для этого я решил использовать следующие технологии (соответственно):

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

Ниже показано, как я планирую настроить тестовую сеть:

Я быстро объясню роли различных частей лаборатории:

Локальный веб-сервер + тестовое устройство

Эта машина - машина, с которой придет разработчик, на котором будет запущен веб-сервер по своему выбору (Apache, Nginx, IIS, что угодно, это не имеет значения). Это удваивается как тестовое устройство. Разработчик должен будет установить некоторое программное обеспечение, которое уведомляет сервер LiveReload об изменении файла (например, охранник-перезарядка). Он будет подключаться к роутеру через WiFi.

Тестовые устройства

Именно из-за мобильных устройств здесь находится лаборатория. Веб-страницы, которые они отображают, можно будет проверять с помощью weinre, обновлять при изменении файла с помощью LiveReload и перемещаться по ним, когда любое другое устройство перемещается с помощью Shim. Они будут подключаться к роутеру через WiFi.

Маршрутизатор

Маршрутизатор будет использовать прокси-сервер для всех запросов, обслуживаемых через порт 80. Он также будет использовать машину прокси-сервера в качестве DNS-сервера.

Прокси-сервер

Этот сервер - больше, чем просто прокси-сервер. В его задачи входит:

TL; DR

Я борюсь со следующим:

Буду очень признателен за ваши мысли.

Возможно, вы ищете функцию ICAP (протокол адаптации интернет-контента).

Существует среда Python, которая справляется с этим (http://icap-server.sourceforge.net/), и у самого Squid теперь может быть функция (по крайней мере в разработке).

Дополнительную информацию (и список других серверов ICAP) можно найти в Squid Wiki по адресу http://wiki.squid-cache.org/Features/ICAP#ICAP_Servers

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

Поэтому я обратился к Apache в качестве прокси. Я настроил его как прозрачный прокси-сервер и настроил цепочку фильтров на раздувание (если содержимое было сдуто), выполнение замены и сдутие (если изначально сдуто). Это работает как шарм.

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

Только с одной точкой доступа у меня была проблема, что исходящий трафик проходил через прокси, а локальный - нет.

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