Как упростить жизнь при работе через VPN

Очень нужна помощь в решении неординарной проблемы.

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

Изначально этот продукт написан индийцами. Что это значит... Это значит, что при каждой загрузке страницы сервис посылает на сервак 500-750 HTTP запросов, 240 из которых — различные ЖС файлы, около 100-150 — картинки для интерфейса, 60-80 штук CSS-ов и т.д. Что такое спрайты, например, разработчики проекта не знали, поэтому даже hover-эффект реализован через отдельные картинки.

В итоге даже с хорошим каналом интернета с малыми пингами перезагрузка страницы занимает от 1.5 до 8 минут — естественно работать так невозможно.

Сразу предваряя наиболее очевидные советы:
— проект написан на достаточно эксклюзивном ЖС фреймворке и все картинки, подключение ЖС-ов и т.д. — все делает фреймворк, заменить на спрайты — в ближайшее время нереально, объединить ЖС-ы в один — тоже, так как все это требует капитального вмешательство в движок фреймворка.
— достучаться до клиента, чтоб он что-то поменял, выдал сорцы или согласился на тотальную переделку — в ближайшее время нереально.
Т.е. единственный для нас вариант (кроме отказа от клиента, а отказ от клиента — не вариант) это как-то ускорить процесс загрузки страниц и всеми возможными способами поднять эффективность работы.

Будем очень признательны если кто-то подскажет какие-то идеи. Например, я рассматривал вариант какой-то прокси, установленной на локальную девелоперскую машину, которая бы кешировала скажем все картинки и ЦСС-ы. Я не силен в администрировании и сетевых ньюансах, но что-то подсказывает что из-за VPN это работать не будет. Может есть еще какие-то варианты?

Заранее спасибо.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Господи, дай сил этим людям освоить кеширующий прокси-сервер. Админь.

Поставьте Fiddler: fiddler2.com
Вы можете использовать его как кэширующий сервер и управлять правилами кэширования. Это делается на вкладке <b>Autoresponder</b>. Fiddler умеет работать с HTTPS, при этом добавляя свой корневой сертификат.

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

Отключается Autoresponder путем снятия галочки на интерфейсе. Ну да, работает под виндовс. Под линух с Wine и Mono не пробовал, но вполне возможно

appdb.winehq.org/...ation&iId=11320

можно подробнее?
я довольно давно знаком с Fiddler2, но такой возможности на Autoresponder’e не видел.
Есть в контекстном меню к правилам пункт «Generate response», который, как на меня, позволил бы сохранить текущий реальный респонс в файл, но у меня этот пункт ни к чему не приводит.
И никакого действия типа «cache and use cached version» я не вижу.
И жуть как мало информации по этим самым пунктам *bpu, *bpafter и т.д.

Вот есть отличный доклад по этой теме. Ссылка ведет на часть с Autoresponder

DDD Brisbane — Mehdi Khalili: ’Advanced Web Debugging with Fiddler
youtu.be/...xnN-k0?t=30m24s

[UPD] нашел в чутка другом месте. спасибо за пинок в нужную сторону.
blogs.msdn.com/...dler-trace.aspx
там просто «перетаскивается» запросы из общего списка в левой части на панель Autoresponder’a — и будет отдаваться сохраненная версия.
P.S. и Generate file работает, но только для правил с префиксом EXACT:

нашел: fiddler2.com/...e/AutoResponder
неожиданно, что не в основном разделе справки по «Modify traffic», где только чуток про autoresponder, а в линейном списке knowledge base.
Но и там ничего про кеширование.

Я немного не понял что вы хотите найти.
Вот пример, как «навсегда» закэшировать картинку в Фидлере, просмотрите и скажите чем он отличается от того, что вы хотите найти.

Вот пример:

  1. Включить AutoResponder
  2. Включить Unmatched requests passthrough
  3. Зайти по URL: i.imgur.com/vTWrVP0.gif
  4. С левой панели Фиддлера с запросами — перетянуть запрос картинки в Autoresponder
  5. Готово. Теперь gif-закешировалась «навсегда» в Фиддлере и теперь браузеры, которые настроены на работу с фиддлером будут получать гифку от фиддлера, а не от сервера.
Вот скриншот:
i.imgur.com/Mg9ATQd.png

Это оно?

это я уже знаю, спасибо
я рассчитывал, что раз вы советуете фидлер человеку под его проблему, то там должен быть какой-то action в зависимости от regex: правила: типа, если CSS/IMG с такого-то сервера, то кешировать

Для того, чтобы захватывать запросы только с одного сервера, можно настроить вкладку Filter. Там есть и поиск подстроки и домен можно отдельно задать для фильтрации.
Потом нужные запросы — перетянуть на AutoResponder. Если необходимо — настроить правила когда отдавать, а когда нет. Там и регекспы есть, которые могут решить, отдавать закэшированую в фиддлере версию на запрос или нет.
А если бы у меня была такая проблема, как и у человека, которому я советую — то для себя я бы как раз все с Фидлером и решил. Хотя, тонкостей оригинальной проблемы я не знаю. Понятное дело, что фидлер — это самое простое и костыльное решение, ниже еще рекомендовали напрячь админа и поставить кэширующий прокси, и еще кучу вариантов. Видимо, автор топика уже себе решение выбрал.

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

Есть, все работает! Еще раз спасибо.

удаленная ws на стороне (в корп сети) клиента + remote desktop of any kind

очевидно же

Если бы на стороне клиента что-то можно было сделать, уже сделали. Вопрос в топике был сформулирован достаточно конкретно.

это

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

«достаточно конкретным» только в пединституте среди пединституток может быть

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

ваша проблема не техническая, а коммерческая, у вас просто плохая договоренность изначально. что нужно попытаться сделать — так это изменить договоренность, а именно 1) контракт должен идти только почасово и без ограничения по верхней границе времени пока им не надоест играться с доступом и 2) только на базе полного доступа, 3) я бы не делала никаких письменных обещаний, ни контракта , и не подтверждала бы эворда — пока не дадут доступ, поскольку они вас фактически подписывают на деливери на базе чужого кода, который они еще и не дают, представьте себе что вы — два игрока, их дело не давать код — ваше дело преследовать свои коммерческие интересы. нежно но настойчиво клюйте их в темечко, чтобы дали доступ — если доступ не дают — предложите переделать все самим с нуля.
аргументы для заказчика могут быть примерно такие: мы потратили ХХ часов for thorough code review and found out that current code does not follow best technology practice (for example ________/описание конкретных ярких случаев что вы заметили что именно сейчас не так / and we foresee that code quality can affect delivery and overall application performance. It’s really important for us to have our customers satisfied with delivery, we would be glad to offer you 2 options on how we could proceed: Option 1 We would be glad to deliver the same scope from scratch, our estimate for that _____ person-hours. Option 2 — perform tech research and bug fix based on the full access credentials provided. ( Или сделайте звонок — это кстати легче всего убедить на звонке а не письменно — что если таск — оптимизация системы — у вас должен быть код — если кода нет, значит по факту нечего оптимизировать. good news — вы можете сделать то же самое с нуля, with well versed acrhitecture, and Sr. developer assigned (это будет выгоднее и проще потому что не надо ковыряться в чужой лапше) — и если они согласны — пусть дают спеку/вайер, мокапы и что там есть еще описывающее, что именно надо сделать. Совет старой офисной черепахи — продумайте самый плохой вариант развития событий — обязательства на основании чужой лапши, гните свою линию про доступ — не идите на уступки — иначе большой риск не разрулить это вообще — кстати на тендерных площадках отсутствие доступа — достаточная причина чтобы отменить проект

У нас нету такой проблемы. Сотрудники на outstaffing-е, данная проблема никак не сказывается на финансовой части сотрудничества и выполнении наших обязательств.

Вы хотите сказать, что их web-based система на вашей стороне тормозит, потому что по VPN она долго грузится? Тогда поставьте на их стороне тазик или виртуалку, запускайте там эту тарабарщину без торозов со стороны VPN, а на тазик этот ходите удалённо по Remote Desktop, который хоть и будет тормозить, но совсем чуть-чуть.

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

Очень сочувствую вашим программистам. Я бы уволился.

Молодец, я за вас рад. Еще один капризный программист с завышенной самооценкой.

Не нужно путать капризы и самооценку с невыносимыми условиями работы.

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

ггггггг, вы щеки-то сдуйте

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

З ваших слів, вас «жостко» обмежує vpn кліент.
І варіантів залишається дуже мало. Ваш варіант з проксею на дев. машині, наприклад, підходить.

Я б спробував спитати у замовника чи є можливість змінити цей кліент, або надати версію під Unix.
Наврятчи там своя реалізація VPN, скоріш за все «під капотом» уже існуюча реалізація чи протокол (той же OpenVPN). Тоді ви зможете поміняти клієнт.

бывает, что ограничение на стороне клиентовского шлюза.
по крайней мере, мне как-то подобное сказали.
в таком случае, действительно, вариант — только кешировать локально :(

Поменяйте VPN клиент на цисковский или openVPN

Вашей конторе явно не хватает админа, который поставит прокси, настроит фишки (gzip/spdy/etc.)

В нашей конторе есть админ. Можете пояснить идею, где ему нужно поставить прокси и настроить фишки?

на роутере весь исходящий траффик на 443 порт в сетку VPN пернаправляем на локальный кеширующий nginx, с включенными модулями gzip и spdy — думаю что даже этот прием «в лоб» сократит время загрузки до 1 секунды ;)

P.S. Админ, это человек, который решает проблемы, а не делает по шагам то, что ему говорят. Увы, но админа у Вас как-бэ нет или он жутко зелен/молод ;)

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

И по gzip
видно не понимание сути проблемы
потому что это повлияет только на объем трафика
а это не критично
нужно урезать количество соединений»

Уверен, что если бы он умел решать проблемы, то Вы бы не искали их решения здесь ;) Это явный признак несостоятельности занимаемой им должности.
По nginx, gzip и VPN есть конретное непонимание у Вашего админа, но если он почитает какой-нить «Getting started with Nginx», как у Nginx и HTTP работает gzip и как делаются прозрачные прокси — то понимание со времем и упорной практикой обязательно придет ;)

Да даже я понимаю что gzip тут вообще никаким боком не имеет отношения к задаче, хоть я и не админ. Если вы считаете, что вы достаточно квалифицированы, ответьте прямо на вопросы:
— КАК архивирование контента gzip-ом уменьшит количество запросов на сервер клиента.
— Про spdy вопрос вы проигнорировали
— Пожалуйста, опровергните утверждение, что нельзя VPN траффик перенаправить на локальный кеширующий сервер средствами nginx

— никто и не гворил что оно уменьшит количество запросов — оно уменьшит скорость загрузки, особенно если этот модуль грамотно настроить в nginx’е

— вы упорно игнорируете гугль — пересказывать тут RFC мне не интересно — вкратце spdy позволяет увеличить скорость загрузки страницы по HTTPS в несколько десятков раз, особенно у индийских фреймфорков ;)

— вы невнимательны при чтении советов, перечитайте чем и где я советовал перенаправить трафик

мое время стоит дорого и тратить его тут на вас я не намерен — гуглите побольше, решайте свои проблемы с админом, мой совет вы уже слышали — его заменой ;)

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

Если бы вы сами почитали про spdy, то понимали бы что в нем есть смысл, если он будет установлен на сервере клиента.

Я внимательно прочитал совет. Вы предложили перенаправить на роутере трафик на локальный nginx, что является наркоманским бредом.

На сим предлагаю эту ветку закрыть — с вашими скилами все ясно.

ну видно сразу, что ваше нежелание разобраться в вопросе и откровенное невежество админа выливаются во вполне закономерную плачевную ситуацию с 8-мью минутами, почитайте на досуге с (админом в обнимку) for ex. про gzip :

developers.google.com/...use-compression

там в первой табличке фэсбук равен индусскому коду — качество одно и тоже, поверьте ;)

А со скилами у меня все пучком, я как-бэ давно директор своей фирмы ... ;)

спасибо, читал, смиявсь

вы очень годный по концентрации лулзов на квадратный комент — так держать, пешыте ещо, т-рищ цео!

ЗЫ знаете, почему в Украине так много г-на, почему грязно так?

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

Пожалуйста, опровергните утверждение, что нельзя VPN траффик перенаправить на локальный кеширующий сервер средствами nginx

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

Некорректно перефразировал фразу «на роутере весь исходящий траффик на 443 порт в сетку VPN перенаправляем на локальный кеширующий nginx, с включенными модулями gzip и spdy»

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

ставить можно только на точку, с которой происходит VPN подключение
И как насчет этого варианта? Какие с ним проблемы? Все остальные будут ходить через этот прокси с других устройств.

Проблема в том, кто клиент навязывает свой собственный VPN клиент, некая такая захардкоженная тулза состоящая из одной иконки в трее — только под Win. Мы не можем воспользоваться другим, тем более мы не можем засетапить его под Unix.

ці дані і треба було вказати в основному питанні!
вони суттєво обмежують вибір рішення.

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

через роутер трафик проходит в пакетах VPN
ставить можно только на точку, с которой происходит VPN подключение

Правильно. Так пусть прокся подключается по VPN куда надо. Тогда на локальных машинах не надо будет поднимать VPN-соединение — им прокся будет и так все отдавать.

потому что это повлияет только на объем трафика
а это не критично

У вас там миллион однобайтовых файлов что ли?...

Ну почти. 700 файлов килобайт этак по 4-5. По сути каждая функция, отрисовывающая какой либо контрол гуя — это отдельный ЖС файл.

Ну а spdy вообще непонятно каким тут боком прилип и как предполагается его использовать. Возникает ощущение что жутко зелен как раз не наш админ :-)

google в помощь, почитайте и не забудьте показать админу ;)

Я понял. С авторитетным видом чушь написать любой может. А когда аргументированно ответить не в состоянии, проще всего к гуглю направить.

сергей какраз правду говорит — поднимите впн соединение на прокси сервере, роути в впн подсеть разрешите только девелоперам проекта, и будет вам щастье

Just FYI, чтобы у вас самого был стимул погуглить. spdy уменьшит количество коннектов между ngxing и браузером. При этом между nginx и сервером клиента все останется по-старому, что не даст вообще никакого положительного результата.

Послушайте. В вас (либо вашем) админе говорит ущемленное ЧСВ. Сдуйте щёчки и сделайте как вам тут уже несколько раз посоветовали.

Считаю неправильным тупо следовать чьим-то безграмотным советам, не задумываясь о том, что они означают.

Подождите, а разве можно кешировать https-запросы? Насколько я понимаю, все http-заголовки передаются уже внутри зашифрованного соединения, или нет?

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

Можно, если забить на невалидный сертификат у прокси — разработчикам это обычно пофигу (мои так два месяца как-то одну CRM отлаживали) :

контора с тупым админом —[https request to VPN]—> router —> local nginx + ssl + spdy + gzip + proxy modules —> индусский сервер

https до nginx здесь используется только ради spdy. в принципе у spdy после nginx прирост небоьшой, если возникают мучения с сертификатами можно остаться на http.

Во сколько часов вы бы оценили настройку всего этого?

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

— squid, как уже советовали. Или что-то из той оперы;
— пусть заказчик вас привезет к себе в командировку — поработаете у него локально плодотворно.

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

Суть в том, что я нагуглил некую тулзу HandyCache. Она кеширует все что угодно кроме траффика на этот сайт — все запросы что идут через VPN, видятся как запросы на один и тот же урл на 443 порт.

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

уть в том, что я нагуглил некую тулзу HandyCache. Она кеширует все что угодно кроме траффика на этот сайт — все запросы что идут через VPN, видятся как запросы на один и тот же урл на 443 порт.
Я не понял из описания, эта тулза работает как прокси для вашего сайта или нет?
Из-за того что на каждый ответ есть какая-то задержка, в сумме на 700 запросов она вырастает до космических масштабов
Ну да, с локальным прокси задержка должна быть минимальной и загрузка ускорится.

HandyCache? Конкретно для нашего сайта, который работает через VPN подключение — нет, она не работает. Возможно конечно что что-то где-то недонастроен, но скорей всего не работает. Каждый http запрос она видит как один и тот же урл на 443 порт и не кеширует его. При этом она исправно работают для нормальных сайтов через нормальное подключение — как например DOU

Ну тогда ставьте какой то кеширующий прокси, сквид например, я правда в этом не разбираюсь.

Каждый http запрос она видит как один и тот же урл на 443 порт и не кеширует его.
Разве это не HTTPS?

вам нужен прокси который работает как man-in-middle с https
оно немного нетривиально, ибо по дефолту все прокси в случае https просто «прокидывают порты»

спасибо, гуглим. Я про такое даже не слышал.

встречал такое в Fiddler2 — прокси специально для разработчиков, с кучей возможностей, но, увы, без проксирования(хотя, особо не искал, может, и есть?)
там генерируется поддельный сертификат, достаточно в браузере ответить «ок, принимаем исключение». и все — можно просматривать/подделывать/трансформировать HTTPS траффик

Підписатись на коментарі