LINUX.ORG.RU
ФорумAdmin

Перенаправление трафика OpenVPN1 через OpenVPN2

 ,


0

2

Доброго времени!

Прошу помощи, т.к. пытаюсь разобраться в вопросе уже несколько дней, но не выходит. Суть такая. Есть два сервера с OpenVPN. Настройки на серверах абсолютно идентичные. Клиент подключен к обоим. Нужно завернуть один туннель во второй. Ввиду непонимания принципов построения сетей, правил и прочего уже перепробовал кучу вариантов из интернета, но ничего не выходит. Многое написанное просто не понимаю. Ощущение, что суперспециалисты пишут для суперспециалистов. Прошу объяснить простым человеческим языком, как можно победить эту задачу. По состоянию на сейчас правила в iptables базовые, т.е. все разрешено. При подключении первого впн весь трафик идет в него на основании приоритета интерфейса. Далее принудительно ограничиваю любые соединения мимо IP этого сервера, подключаю второй ВПН. Он, как ни странно подключается. То есть я думал, что туннель поднимается внутри первого туннеля. Но затем я повышаю приоритет у второго ВПНа и инет пропадает…

Нужно завернуть один туннель во второй

+--------+     +--------+      +--------+     +--------+
| Client | <-> |  OVpn1 |  <-> |  OVpn2 | <-> |  Dest  |
+--------+     +--------+      +--------+     +--------+

Верно?
Клиент должен пинговать трафик Dest?

Или у вас так?

Клиент подключен к обоим

               +--------+
+--------+ --> |  OVpn1 |
| Client |     +--------+ 
+--------+ --> |  OVpn2 |
               +--------+
i3wm
()
Ответ на: комментарий от lobanov18

Ок.
Как я понимаю Вам нужно чтобы клиент при подключении второго туннеля (назву его локальним) - слал туда только некоторый трафик?
Примером, что-то из енной подсети?

             +--------+     +--------+    
           / |  OVpn1 | --> | Global | 
+--------+   +--------+     +--------+
| Client |     
+--------+ 
           \ +--------+     +--------+
             |  OVpn2 | --> |  Local | 
             +--------+     +--------+

Или же нужно, чтоб клиент ходил на OVpn2 через OVpn1.

             +--------+   
           / |  OVpn1 | 
+--------+   +--------+ 
| Client |        |
+--------+        |
             +--------+   
             |  OVpn2 |  
             +--------+ 
i3wm
()
Ответ на: комментарий от i3wm

Да, второй вариант верный. Его и пытаюсь добиться. Сначала поднимаю первый туннель до VPS1, затем внутри него второй до VPS2. Как я понимаю, при таком подключении провайдер видит ip первого туннеля (VPS1), а внешние ресурсы ip второго (VPS2). VPS2 также видит только ip VPS1. Тем самым достигаем условно неплохой анонимности. Хотя есть мнение, что при таком подключении VPS2 будет видеть ip клиента. Но это я не могу подтвердить или опровергнуть, пока не построю схему и не увижу логи второго сервера на практике. А пока как я понимаю, у меня поднимаются два параллельных туннеля. При этом для меня загадка, как умудряется параллельно подняться туннель до VPS2 после того, как я ограничил передачу трафика мимо VPS1 и почему после этого трафик не хочет идти через VPS2.

lobanov18
() автор топика
Ответ на: комментарий от i3wm

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

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

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

i3wm
()
Ответ на: комментарий от i3wm

Благодарю за ссылки. По первой все очень доходчиво. Но затык в том, что у меня есть клиентский файл настроек ovpn. Он сразу содержит все ключи, без проблем экспортируется и появляется настройка. После добавления указанных строк в этот файл, система при экспорте выдает ошибку: —Модулю VPN не удалось правильно импортировать VPN-соединение. Файл ключей содержит строку «client», которая не является парой «ключ-значение», группой или комментарием—

Вот изначальный конфиг:

client dev tun proto udp remote Х.Х.Х.Х 1194 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server auth SHA512 cipher AES-256-CBC ignore-unknown-option block-outside-dns block-outside-dns verb 3 —–BEGIN CERTIFICATE—– …

Указанные по ссылке строки добавляю после remote X,X,X,X 1194

Что я делаю неправильно?

lobanov18
() автор топика
Ответ на: комментарий от i3wm

Извиняюсь, строки немого поехали в сообщении…

lobanov18
() автор топика
Ответ на: комментарий от i3wm

И еще вопрос. На обоих серверах следующие конфиги:

local 172.31.19.249
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem auth
SHA512 tls-crypt
tc.key
topology subnet
server 10.66.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push «redirect-gateway def1 bypass-dhcp»
push «dhcp-option DNS 172.31.0.2»
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Правильно ли понимаю, что строку push «redirect-gateway def1 bypass-dhcp» следует удалить на первом сервере, а на втором сервере строку push «dhcp-option DNS 172.31.0.2» привести в соответствие с настройкой второго клиента, т.е. push «dhcp-option DNS 10.66.1.1» ?

lobanov18
() автор топика

Серверами VPN управляете вы? В таком случае, проще всего настроить перенаправление порта средствами iptables с VPN1 на VPN2, и, подключаясь к серверу VPN1, вы на самом деле будете подключаться к VPN2.

Второй вариант: https://qna.habr.com/q/677086#answer_1469521

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

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

lobanov18
() автор топика
Ответ на: комментарий от ValdikSS

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

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Нужно менять конфигурацию на клиенте, а не на сервере. Чего вы хотите добиться в итоге? Зачем вам два VPN?

Если вы хотите, чтобы IP-адрес подключения клиента не совпадал с IP-адресом, который видят сайты, настройте VPN только на втором сервере, а на первом сделайте что-то вроде:

iptables -t nat -d IP-АДРЕС-ЭТОГО-СЕРВЕРА -p tcp --dport 1194 -j DNAT --to IP-АДРЕС-СЕРВЕРА-VPN

Попутно ещё нужно будет включить forward через sysctl.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Я хочу добиться варианта, при котором провайдер видит подключение к серверу 1, сервер 2 видит сервер 1, внешние сайты видят сервер 2.
Я не понимаю описанный Вами вариант. Клиент подключается к первому серверу по ВПН, а на втором сервере прописывается это правило и включается forward? Если да, то как с помощью этого правила первый сервер пойдет в сеть через второй сервер?
Поменял конфиг первого клиента. Проблема осталась. Подключаюсь к ВПН1 - интернет идет мимо него, подключаюсь к ВПН2 - интернет начинает идти через ВПН2. Далее дропаю выход в инет через любые IP кроме ВПН1 и пакеты перестают уходить. Вывод - второй туннель не завернулся в первый.

lobanov18
() автор топика
Ответ на: комментарий от anc

С него эпопея и начиналась, но я попытался реализовать его по одному из мануалов, потратил несколько часов и ничего не добился. А учитывая, что сервера надо по хорошему периодически менять, я не готов каждый раз проделывать такие процедуры. То, что я хочу называется ParallelVPN и мне он показался сильно проще в реализации, когда готовые сервера скриптом поднимаются за 1 минуту…

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Ввиду непонимания принципов построения сетей, правил и прочего
Многое написанное просто не понимаю.
потратил несколько часов

Вы хотите получить ответ на неполностью оформленный ТЗ ? Ну что же, удачи вам «макака копипаста».

anc ★★★★★
()
Ответ на: комментарий от anc

Не могли бы Вы подсказать, как создать «полностью оформленный ТЗ»? Я полагаю, что довольно понятно сформулировал свою задачу.

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Ваша задача сформулирована на уровне телепатов. За вас рисуют только предполагаемую схему. От вас ответы:

да, у меня вторая схема.
Да, второй вариант верный.

Предложенные вам схемы противоречат друг другу. Но вы подтверждаете как «макака» «мне нравиться банан слева».

Рисуйте сами, а не подтверждайте предполагаемый. С полным описанием.

Если вы хотите туннель в туннеле, то тоже нет проблем такое построить. Однако надо как минимум прилагать те конфиги (со всех точек) которые уже пробовали и что именно не получилось.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от lobanov18

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

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

Если надо подробней - говори изначальную задачу, для чего каскад vpn хочешь организовать?

mogwai ★★★★
()
Ответ на: комментарий от anc

Да причем тут «предложенные схемы»? Я в первом сообщении написал, что есть два туннеля, подключенные к клиенту. Идентичные. Нужно один направить в другой. Что в этом описании не понятно? Где телепатия? Вы не можете себе представить два туннеля и клиента? В чем предложенные мной схемы противоречат друг другу? Особенно учитывая, что я как предложил одну, так ее и придерживаюсь. Я в том же первом сообщении белым по серому написал, что да, хочу завернуть туннель в туннель. Вы вообще это сообщение читали прежде чем незнакомого человека макакой называть или сразу с середины темы чтение начали? Конфиг клиента и сервера приведен также выше. Что не получилось также написано в теме. И все мои вопросы относительно двух предложенных решений заданы авторам этих предложений. А в ответ только комментарий про макаку от человека, который и не предложил ничего. Вы говорите, что нет проблем ВПН в ВПН завернуть. Ну так подскажите уже, как это сделать. А я обнулю сервера, в которых уже запутался и буду пытаться.

lobanov18
() автор топика
Ответ на: комментарий от mogwai

Проблема в том, что для меня фраза

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

понятна в теории, как это сделать на практике я не понимаю.

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

Это дабл впн. От него я отказался ввиду множества заморочек.

Если надо подробней - говори изначальную задачу, для чего каскад vpn хочешь организовать?

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

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

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

Начнем с этого. Может все-таки клиент подключается к серверу? А не наоборот?

Конфиг клиента и сервера приведен также выше.

Клиента не увидил (точнее пропустил глупость). Сервер Перенаправление трафика OpenVPN1 через OpenVPN2 (комментарий)
Правда два одинаковых конфига?

Вот вы серьезно, с такой постановкой задачи хотите получить ответ?

Понимаете ли есть интересные задачи от ТС-ров. Например несколько лет назад подкинули вариант сохранения внутреннего ip при множестве серверов ovpn и сохранения связности сетей. Это было интересно порешать, даже на уровне тестов. Решение описано мной на этом форуме.
Но ваш вопрос пока не содержит задачи. Точнее пока это все ещё double vpn, который описан в большом кол-ве тем.

anc ★★★★★
()
Ответ на: комментарий от anc

Начнем с этого. Может все-таки клиент подключается к серверу? А не наоборот?

И ведь не поспоришь…

Правда два одинаковых конфига?

Уже сомневаюсь. Но по-прежнему не понимаю, чем они отличаются.

Вот вы серьезно, с такой постановкой задачи хотите получить ответ?

Я продолжаю не понимать, что не так с постановкой задачи…

Понимаете ли есть интересные задачи от ТС-ров. Например несколько лет назад подкинули вариант сохранения внутреннего ip при множестве серверов ovpn и сохранения связности сетей. Это было интересно порешать, даже на уровне тестов. Решение описано мной на этом форуме. Но ваш вопрос пока не содержит задачи. Точнее пока это все ещё double vpn, который описан в большом кол-ве тем.

Если Вам эта задача не кажется интересной, просто не участвуйте в ее решении.

Видимо мы разговариваем на разных языках. Я не специалист по сетям и правилам, о чем сообщил выше неоднократно. Но за несколько дней изучения вопроса я понял, что DoubleVPN - это последовательно подключенные сервера, а ParallelVPN - это VPN внутри другого VPN. Также выше я сформулировал, что требуется, чтобы провайдер не знал о существовании VPN2, а внешние ресурсы о VPN1. Этому условию, если я правильно понимаю, соответствует как Double, так и Paralle VPN. Но попробовав настроить вручную Double VPN я отчетливо понял, что это весьма трудоемкое занятие по отношению к двум поднятым на автомате туннелям, которые теперь осталось только организовать на стороне клиента.

lobanov18
() автор топика
Ответ на: комментарий от anc

Ловите дилера/террора.

Вынужден разочаровать. Анонимность нередко нужна и во вполне законной деятельности. Если у Вас нет предложений по существу, прошу не флудить больше в этой теме, есть много других…

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Уважаемый ТС. Уж простите но все проблемы начинаются со слов «теперь осталось только...».

Уже сомневаюсь. Но по-прежнему не понимаю, чем они отличаются.

Тащето это был вопрос: «Правда два одинаковых конфига?». Если да, ну повторно удачи вам.

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

Интересно каким местом вы это поняли? Как раз double vpn в части клиентской настройки в разы проще получаеться. А то что вы написали вам выше Перенаправление трафика OpenVPN1 через OpenVPN2 (комментарий) не прозрачно mogwai намекнул.

anc ★★★★★
()
Ответ на: комментарий от lobanov18

Выше вам уже писали, но вы не поняли. Пояснее второй раз, «Location A» упала вы пойдете напрямую на «Location B».
Сколько раз падало соединение между Вашим компом и «Location A» и было соединений на «Location B» на прямую? Это или в отслеживании логов или в «спортлото». Но вам от этого легче, узнать пост фактум? Задача не выполнена.

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

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Для таких неприятностей у меня есть запрет трафика мимо IP внешнего туннеля, о чем я уже несколько раз написал. Теперь схема рабочая?

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Я не понимаю описанный Вами вариант. Клиент подключается к первому серверу по ВПН, а на втором сервере прописывается это правило и включается forward? Если да, то как с помощью этого правила первый сервер пойдет в сеть через второй сервер?

Вы прописываете это правило на сервер, на котором не будет установлен VPN, а он перенаправляет трафик на сервер VPN.
У вас будет всего один VPN, а не два.

Вывод - второй туннель не завернулся в первый.

Вывод неправильный.

ValdikSS ★★★★★
()
Ответ на: комментарий от lobanov18

Не оставлю вам шанса увернуться от прямого ответа. Эта схема завернет один туннель в другой?

В этой схеме отсутствует «у меня есть запрет трафика мимо IP внешнего туннел» Точнее отсутствует сама схема. Так надеюсь понятнее? Вот недавно пролетевшая тема, у ТС (той темы) тор ставит attr +i на resolv.conf. Вопрос знатокам зачем это сделано? Так вот и у вас, полной схемы нет, пытаемся «что-то» «как-то» сделать.

anc ★★★★★
()
Ответ на: комментарий от ValdikSS

Вы прописываете это правило на сервер, на котором не будет установлен VPN, а он перенаправляет трафик на сервер VPN. У вас будет всего один VPN, а не два.

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

При попытке создать это правило выдает ошибку: iptables v1.6.1: no command specified

Вывод неправильный.

Если я поднимаю один туннель и ставлю ограничение трафика по всем IP кроме IP туннеля, то ничего с трафиком не происходит, пока туннель активен. А тут не могу понять, в чем причина. Единственное логичное объяснение - tun1 не внутри tun0.

lobanov18
() автор топика
Ответ на: комментарий от anc

Вы издеваетесь? Я прямо спросил: согласно приведенной картинке tun1 окажется внутри tun0? Если не знаете, то так и скажите.

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Вы издеваетесь?

Только отчасти

Я прямо спросил: согласно приведенной картинке tun1 окажется внутри tun0?

maybe rain, maybe snow, maybe yes, maybe no.
Вы так и не поняли? Что будет при падении туннелей? Нет вы «гордо сказали что у меня» «есть запрет трафика мимо IP внешнего туннел» мы вам наверное поверили. И даже порадовались за вас.

anc ★★★★★
()
Ответ на: комментарий от lobanov18

При попытке создать это правило выдает ошибку: iptables v1.6.1: no command specified

Это просто пример правила, его одного недостаточно. Нужно добавить правило с DNAT в PREROUTING, правило с SNAT или MASQUERADE в POSTROUTING, желательно правильно указав интерфейсы и IP-адреса. Также необходимо включить саму подсистему маршрутизации, и не забыть настроить таблицу FORWARD, чтобы через ваш сервер не маршрутизировали лишнего.

Если я поднимаю один туннель и ставлю ограничение трафика по всем IP кроме IP туннеля, то ничего с трафиком не происходит, пока туннель активен. А тут не могу понять, в чем причина.

Я не понимаю вашу терминологию. Что значит «ничего с трафиком не происходит», туннель продолжает работать?

Единственное логичное объяснение - tun1 не внутри tun0.

Если вы настраиваете вариант по ссылке, то у вас маршрутизация IP-адреса VPN2 будет происходить через VPN1, а маршрут по умолчанию будет установлен в VPN2, как только вы подключите оба соединения.
Если вы заблокируете IP-адрес какого-либо VPN-сервера, соединение работать не будет.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Я не понимаю вашу терминологию. Что значит «ничего с трафиком не происходит», туннель продолжает работать?

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

Если вы настраиваете вариант по ссылке, то у вас маршрутизация IP-адреса VPN2 будет происходить через VPN1, а маршрут по умолчанию будет установлен в VPN2, как только вы подключите оба соединения. Если вы заблокируете IP-адрес какого-либо VPN-сервера, соединение работать не будет.

Вот этого и не понимаю. Как тогда удостовериться, что трафик остался внутри tun0? Как избежать прямого подключения tun1 в случае отключения tun0 и что еще хуже прямого подключения к инету в случае отключения tun1?

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

Вот этого и не понимаю.
Как тогда удостовериться, что трафик остался внутри tun0?

На «савеле» купите хрустальный шар, может он поможет. Реальные варианты в виде tcpdump, ip r s table all, ip ru и так далее не предлагаю.

anc ★★★★★
()
Ответ на: комментарий от ValdikSS

Похоже, я понемногу догоняю, как все происходит… Ваш метод работает. Вот что получилось:

$ ip route
0.0.0.0/1 via 10.8.1.1 dev tun1
default via 10.0.2.2 dev eth0 proto dhcp metric 200
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 200
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.2
XXX.XXX.XXX.XXX via 10.0.2.2 dev eth0
YYY.YYY.YYY.YYY via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.1.1 dev tun1

Если правильно понимаю, три нижние строки отражают, что сетевой интерфейс eth0 соединяется с tun0 (ХХХ.ХХХ.ХХХ.ХХХ), а tun0 c tun1 (YYY.YYY.YYY.YYY). Начинаю понимать логику, почему при дропе всего кроме XXX.XXX.XXX.XXX поднимались оба туннеля. Первый потому, что это его адрес, второй потому, что сначала он также обращается на адрес первого сервера. А потом начинается маршрутизация, и все пакеты летят на YYY, который дропнут.
Вот чего не могу понять, так это почему после подключения к первому серверу пакеты улетают в сеть напрямую и как этого можно избежать. Хотя если дропнуть все кроме ip обоих серверов, то это решит проблему утечки реального адреса. Остается под вопросом, как остановить пакеты при падении одного из туннелей… А возможно route-nopull и две другие строки из конфига клиента прописать в конфиг сервера? Они же точно также через push сработают? А то NetworkManager отказывается работать с такими файлами и приходится запускать конфиг клиента из командной строки, что не очень удобно.

lobanov18
() автор топика
Ответ на: комментарий от anc

Как бы там не было, спасибо вам. Вы помогли, хоть и своеобразно. Но я в описанных в вашем последнем сообщении штуках совершенный ноль. Правильно ли я понял логику, которую описал в предыдущем сообшении? Как можно решить проблему падения внешнего туннеля? Если можно, то конкретным примером, а не перечислением команд. Иначе точно не разберусь. И что скажете по поводу остальных вопросов?

lobanov18
() автор топика
Ответ на: комментарий от lobanov18

почему после подключения к первому серверу пакеты улетают в сеть напрямую

Потому что установлен маршрут через VPN только до другого сервера VPN.

Я вам написал простое и удобное в использовании решение — перенаправление порта на одном из серверов. Если вас это не устраивает, то вам придется городить собственные скрипты для установления обоих VPN-соединений самостоятельно.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

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

lobanov18
() автор топика
Ответ на: комментарий от ValdikSS

Вас дезинформировали.

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

Это просто пример правила, его одного недостаточно. Нужно добавить правило с DNAT в PREROUTING, правило с SNAT или MASQUERADE в POSTROUTING, желательно правильно указав интерфейсы и IP-адреса. Также необходимо включить саму подсистему маршрутизации, и не забыть настроить таблицу FORWARD, чтобы через ваш сервер не маршрутизировали лишнего.

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

lobanov18
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.