Перейти к содержимому
Калькуляторы

l2 туннель через два малонадежных мобильных канала

1 минуту назад, LostSoul сказал:

главное чтоб в ядре уже был tun/tap модуль собран, через который он работает

Openvpn tun tap пашет  - значит есть

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, Smirnovi сказал:

Openvpn tun tap пашет  - значит есть

логично, да

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все же не хочеца без элементарной авторизации l2tp без ipsec меня спасет?

да и айпишник белый но не статический и нехочеца статик покупать

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 часа назад, Smirnovi сказал:

все же не хочеца без элементарной авторизации l2tp без ipsec меня спасет?

не покупайте статик.

сделайте скрипт, который будет по ddns микротиковскому актуализировать настройку eoip это несложно

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

12 часов назад, LostSoul сказал:

сделайте скрипт, который будет по ddns микротиковскому актуализировать настройку eoip это несложно

понял спасибо

кcати eoip на gre 

у меня pptp легко проходит через сеть всех нужных мне операторов и их нат

 

а как пропихивать l2tp чистый через нат я так и не нащел

возможно только что ipsec и nat-t

 

 

был бы благодарен если выложили скрипт под нуклеркат еиайпи

и как собрать модуль самому под мое ядро линукса

 

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

Изменено пользователем Smirnovi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Eoip это не совсем gre но сделан на его основе, поэтому большинство bat alg от gre обеспечивают его работу.

2. Сборка модулей вам не требуется , если tun tap уже в ядре

3. Если у вас на лтнуксе тоже нет белого Ip то можно сделать dnat на него протокола gre , но с вашим уровнем понимания я бы такой вариант не рассматривал

 

4 мой скрипт ifcfg-eoip он под red hat / centos / fedora и не заработает с другим дистрибьютивом линукс

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я в недоумении 

мне проще настроить два микротика 

один который за моб роутером и операторским натом а второй виртуализованный за натом линукс роутра с белым айпи

но проприетарный eoip такие наты не пролезет

 

а если настраивать eoip на линукс роутре asuswrt с прошивкой merlin 

это надо компилировать сам eoip модуль 

плюс хз как будет в нем пахать и возможен ли вообще bonding boadcast или хотяб balance-rr

да и вобще этот роутер основной тревожить его настройки попусту бы не хотелось

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

 

оттого спрошу есть ли всеже вариант поднять изначальные туннели на l2tp ipsec оно ведь на udp

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднимаете туннели L2TP через разных операторов.

Настраиваете на каждый свою подсеть.

Включаете OSPF, микротики обмениваются маршрутами и все работает.

Создаете по пустому бриджу на каждом микротике.

Вешаете на пустой бридж уникальный IP без маски.

Поднимаете EoIP туннель между этими IP адресами.

На OSPF включаете BFD, указав нужное время.

 

Все будет само работать и переключаться.

 

Есть вариант без L2. Вешаете на порты адреса по схеме вида IP = 10.10.10.1, Network = 10.10.10.123 - этот адрес указываете на оконечном устройстве. Включаете прокси арп. С другого микротика аналогично. Тогда в списке маршрутов на каждом микротике будет адрес соседа, и подключенные к микротику устройства смогут обмениваться данными по L2 через L3.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 часов назад, Smirnovi сказал:

я в недоумении 

мне проще настроить два микротика 

один который за моб роутером и операторским натом а второй виртуализованный за натом линукс роутра с белым айпи

но проприетарный eoip такие наты не пролезет

это совсем даже не проще.

не говоря уже про скорость работы виртуализированного микротик на роутере asus ( если у вас вообще получится это запустить )

 

linux eoip это НЕ МОДУЛЬ ЯДРА

Это простой userspace демон, простейший , работающий через tun/tap и с его сборкой под любую платформу никаких проблем, он простейший.

13 часов назад, Smirnovi сказал:

плюс хз как будет в нем пахать и возможен ли вообще bonding boadcast или хотяб balance-rr

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

 

13 часов назад, Smirnovi сказал:

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

 

вы проигнорировали мой вопрос, зачем вам вообще нужна такая задача - вещать FullHD видео куда-то там через 2 неустойчивых 4G канала.

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

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

 

 

1 час назад, Saab95 сказал:

Все будет само работать и переключаться.

 

Этот вариант уже предлагали выше.

Он имеет два недостатка -

1) затык на время переключения ( отработки bfd )

2) некорректную отработку bfd если пакеты перестанут доходить лишь в одном направлении

3) хреновую работу в целом при высоком уровне потерь ( когда нету дублирования каждого пакета разными путями )

4) в целом крайне хреновую работу l2tp при высоком уровне потерь, так как этот тип vpn ориентирован на соединения ( необходима авторизация и согласование сессии , а при высоком дропе оно уже на этой стадии будет фейлить и не подниматься )

 

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

 

 

1 час назад, Saab95 сказал:

 

Есть вариант без L2. Вешаете на порты адреса по схеме вида IP = 10.10.10.1, Network = 10.10.10.123 - этот адрес указываете на оконечном устройстве. Включаете прокси арп. С другого микротика аналогично. Тогда в списке маршрутов на каждом микротике будет адрес соседа, и подключенные к микротику устройства смогут обмениваться данными по L2 через L3.

Никакое прокси arp ему не поможет.

Автор хочет чтоб у него multicast пакеты SDP от DLNA проходили.

Но это разумеется не единственный вариант трансляции fullhd видео с линукса на андроид

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

32 минуты назад, LostSoul сказал:

1) затык на время переключения ( отработки bfd )

2) некорректную отработку bfd если пакеты перестанут доходить лишь в одном направлении

3) хреновую работу в целом при высоком уровне потерь ( когда нету дублирования каждого пакета разными путями )

4) в целом крайне хреновую работу l2tp при высоком уровне потерь, так как этот тип vpn ориентирован на соединения ( необходима авторизация и согласование сессии , а при высоком дропе оно уже на этой стадии будет фейлить и не подниматься )

1. Затыков с bfd нет, если данные перестанут идти, не зависимо от состояния интерфейса, он исключается из работы OSPF.

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

3. Если MTU убавить, то через сотовых обычно нет потерь, пока не превышать некую скорость.

4. Канал не будет обрываться при потерях, просто пойдут дропы и все.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

48 минут назад, Saab95 сказал:

1. Затыков с bfd нет, если данные перестанут идти, не зависимо от состояния интерфейса, он исключается из работы OSPF.

 

Сааб не читатель, Сааб писатель?

Вот представьте - на вход данные идут , а на выход канал умер.

Что будет делать bfd? 

Правильно - ничего. данные же идут.

Получаем неработоспособный линк.

 

Насчет "потерь нет" - вы придите в какое-нибудь густонаселенное место типа входа в станцию метро в 18 часов вечера и посмотрите как оно не будет теряться.

 

 

53 минуты назад, Saab95 сказал:

4. Канал не будет обрываться при потерях, просто пойдут дропы и все.

канал будет отваливатся по таймауту

а потом просто не будет успевать поднятся

если вам показать подобную работу 4g то вы вообще скажите что использовать указанное оборудование и линк невозможно

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

причем без буферизации и повторных отправок пакетов

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, LostSoul сказал:

Вот представьте - на вход данные идут , а на выход канал умер.

Что будет делать bfd? 

Правильно - ничего. данные же идут.

Получаем неработоспособный линк.

BFD знаете что такое? Bidirectional Forwarding Detection, проверяется именно двунаправленность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

15 минут назад, vurd сказал:

BFD знаете что такое? Bidirectional Forwarding Detection, проверяется именно двунаправленность.

неужели?

и как тогда она будет мгновенно регистрировать отказ канала, у которого лаг туда-обратно 4000мс?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 минуты назад, LostSoul сказал:

неужели?

и как тогда она будет мгновенно регистрировать отказ канала, у которого лаг туда-обратно 4000мс?

 

Оно не будет на таком канале работать. Очевидно, не?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

26 минут назад, vurd сказал:

Оно не будет на таком канале работать. Очевидно, не?

Для меня не очевидно.

Я полагал что это работает так - из трубы валятся нумерованные seq пакеты с определенным интервалом, после того как n  ожидаемых пакетов не поступило - канал считается погасшим.

Ничего из части biderectional я в данном протоколе за все свое время его использования не наблюдал.

То есть мои выводы о природе его работы строятся из наблюдений. rfc или исходники не читал.

Но у меня в нескольких местах bfd нормально работает в ситуациях, когда RTT к примеру 100мс , а dead time - 20мс

и оно работает устойчиво пока реально линк не рухнул

 

 

а вот описание работы протокола из интернета

Цитата

Каждый из смежных маршрутизаторов, на которых настроен протокол BFD, периодически посылает «Hello» сообщения своему соседу. Получение данного сообщения означает работоспособность канала в одном определенном направлении, неполучение «Hello» сообщения говорит о неработоспособности канала, что и фиксирует протокол BFD. По умолчанию, на неработоспособность канала указывают 3 подряд не полученных  пакета «Hello». Количество пакетов и их интервал отправки может быть изменен при конфигурации протокола.

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

Это протокол для БЫСТРОГО переключения.  А он просто не может быть быстрым, если ему для принятия решения требуется ждать 1 или более RTT.

 

Почитал еще подробнее.

Бывает BFD Async и BFD Auto режимы ( на циско ).

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Угу. Есть echo-режим.

 

А вообще погасит канал другая сторона, она разорвет соседство и всё. Технически нет разницы, кто не получил хелло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 минут назад, vurd сказал:

А вообще погасит канал другая сторона, она разорвет соседство и всё. Технически нет разницы, кто не получил хелло.

Никак она его в режиме async не погасит. Нету у нее для этого механизму.

просто та сторона будет трафик слать по одному пути ( пометив этот как неактивный ) , а микротик с той стороны куда прием hello идет будет продолжать слать "в стену"

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 30.09.2018 в 10:16, LostSoul сказал:

да потому что вторично.

тоже заморачивался этой темой.

главная задача - как сделать надежный канал из 2 нестабильных.

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

в принципе , для варианта tcp  достаточно просто bonding c режимом broadcast , tcp сам проигнорирует дубли.

я так mp3 радиовещание дублировал.

 

для универсальности типа udp нужно пакетам какие-то id делать.

Ну или, как черезжопный вариант как раз поверх bonding broadcast сверху openvpn через tcp поднять чтоб он дедуплицировал все :-)

 

более-менее сносно это будет работать , разумеется, только при полной гарантии что хотя бы по одному из путей каждый конкретный пакет дойдет быстро и без ошибки

 

 

 

Очень долго писать, телефон в подписи, звоните, расскажу много интересного на эту тему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

16 минут назад, grifin.ru сказал:

Очень долго писать, телефон в подписи, звоните, расскажу много интересного на эту тему.

Это Смирнову не видно, я свою задачи успешно решил давно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 часов назад, LostSoul сказал:

вы проигнорировали мой вопрос, зачем вам вообще нужна такая задача - вещать FullHD видео куда-то там через 2 неустойчивых 4G канала.

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

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

Вообщем задачка нетривиальная но и не невыполнимая как я понял из Ваших советов.

Никаких реалтайм передач видео и аудио по броадкасту и/или в udp нету.

 

Андроид как известно не позволяет ввиду использования fat32 хранить больше 4 гигов в 1 файле с любым объемом файловой вобще (огранич fat32).

да и устанеш запихивать на флешку 10 и более гигов за раз

подключать внешнюю по otg  тоже изврат а тем более хард на юсб хабе с внешним питанием еще больший изврат 

А хочеца смотреть кино на разрешениях не больше fullhd по сети не только в пределах одной подсети и точки доступа.

Это уже настроил и этого мало мне.

 

Есть программа просмотра 3D  VRTV - она точно переваривает upnp/dlna - подхватывая ссылку или поток от BubbleUPNP

этот режим я проверил смотря видео через локалку и вифи с homemedia server

хз как с таймаутами и кешированием у этой связки - буду искать настройки 

 

самба знаю работает по tcp а сетевое окружение читал требует броадкастов 

смб протокол еще не проверял - но возможно !!! оно  на андроиде и vrtv потребует видимости компьютера в сетевом окружении 

сегодня буду настраивать 

 

есть несколько lte устройств и симок операторов на разных вышках

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

ну и 3 обычный режим серфинга - в котором неважна скорость 

 

схема такая 

 

Андроид ->wifi -> mikrotik -> Lte роутер -> сеть моб оператора с операторским натом ->интернет -> Линукс роутер asuswrt с нат разумееца -> компьютер с windows dlna и расшаренной папкой smb (возможно внутри виртуализованный микротик наверно проще на него dmz кинуть)

 

Вот такая вот схема

 

ps так понимаю из объяснений выше что opsf и bfd мне не подойдет?

linux eoip нашел два : от нуклеарката и еще один

какой собирать?

и у нуклеарката он на гуглекоде и гитхабе - и какую версию собирать?

 

решено роутер asuswrt у меня боевой - подниму виртулку в винде на centos x64

поделитесь скриптом пожалуйста и модулем 

Изменено пользователем Smirnovi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, grifin.ru сказал:

Очень долго писать, телефон в подписи, звоните, расскажу много интересного на эту тему.

Напишите пожалуйста тут если можно - текстом нагляднее

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, Smirnovi сказал:

вот и хочу обеспечить 1 надежное непрерывное прохождение такого потока с редкими по времени паузами

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

Каждая из поднятых вами проблем решается множеством гораздо более прямых способов.

Есть иные файловые системы которые поддерживает андроид.

Хотя бы тот-же exFAT , который поддерживается и в Андроид, и в Windows начиная аж с Windows XP и в любом линукс.

Есть возможность организации "фильма" или иного контента с раскладкой его в куски менее 4 гигабайт  ( тот же DVD / BlueRay многие так )

Для работы smb протокола , вопреки вашему заключению абсолютно не требуется broadcast.

Может быть он требуется для отображения "сетевого окружения" в одной из ваших высокоуровневых оболочек ( может 3D VRTV это оно ) , но точно не требуется чтоб подключить на андроиде сетевую папку.

кроме самбы есть и nfs и plan7 и много много вариантов.

есть в конце концов torrent tv с возможностью распаралелить загрузки чанков по разным каналам.

 

Вы в целом решаете какую-то исходную задачу черезжопным методом.

 

Лень нарезать 30 гигов на флешку?

Может вы типа хотите "отправлять фильмы на телевизор на дачу из городской квартиры"?

Так для этого есть куча готовых решений, тот же resilio к примеру https://ru.wikipedia.org/wiki/Resilio_Sync

 

если вам не нравится подключение диска через OTG - есть дисковые накопители с езернетом , типа WD My Cloud по вполне гуманным ценам.

А есть и андроид-платы с встроенным SATA типа cubietruck ( и гораздо дешевле даже чем WD My cloud )

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

21 час назад, LostSoul сказал:

Вот представьте - на вход данные идут , а на выход канал умер.

Что будет делать bfd? 

Правильно - ничего. данные же идут.

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

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

Но если канал упал, то после 3 потерь он будет отключен, и другая сторона так же отключит его.

 

21 час назад, LostSoul сказал:

канал будет отваливатся по таймауту

а потом просто не будет успевать поднятся

Ничего такого не происходит. Если таймаут 10-20 секунд, то отвалившись на клиенте, на сервере он будет 10-20 секунд висеть, а клиент будет делать реконнект, но сервер будет отбрасывать его пакеты. Но после этого времени соединение произойдет. А если канал настолько плохой, что соединение не поднимается, то зачем его использовать? И что, какие-то другие протоколы смогут на нем лучше работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 минуты назад, Saab95 сказал:

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

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

Но если канал упал, то после 3 потерь он будет отключен, и другая сторона так же отключит его.

Я как раз хорошо понимаю как это работает.

Поэтому утверждаю - на микротиках с BFD это самое BFD при нарушении проходимости канала в одну сторону работать не будет.

Точнее сработает в одну сторону ( канал заблокируется как раз в ту сторону, в которую он пропускает трафик, и НЕ заблокируется в отказавшем направлении )

И ospf работающий датаграммами через мультикаст скорее всего поведет себя ровно так-же --   маршрут будет сохранен на неисправный интерфейс  в том направлении куда трафик НЕ проходит, а с другой стороны маршрут будет снят ( куда трафик мог бы проходить )

Насчет ospf не уверен , давно крутил. Но вроде так.

7 минут назад, Saab95 сказал:

Ничего такого не происходит. Если таймаут 10-20 секунд, то отвалившись на клиенте, на сервере он будет 10-20 секунд висеть, а клиент будет делать реконнект, но сервер будет отбрасывать его пакеты. Но после этого времени соединение произойдет. А если канал настолько плохой, что соединение не поднимается, то зачем его использовать? И что, какие-то другие протоколы смогут на нем лучше работать?

Естественно есть.  И об этом данная тема.

Можно организовать стабильный канал даже при наличии 70-80% packet drop , главное чтоб не по всем составляющим канала одновременно.

( то есть причина не мощная скажем импульсная помеха возле нашего устройства )

Нужно просто ДУБЛИРОВАТЬ пакеты , через НЕСКОЛЬКО туннелей , построенных на connection less концепции

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, LostSoul сказал:

Нужно просто ДУБЛИРОВАТЬ пакеты , через НЕСКОЛЬКО туннелей , построенных на connection less концепции

 

Понял Вас - этот вариант самый надежный 

оно у меня прокатит с моей схемой через несколько nat с eoip от nuclearcat ?

нат операторском и моим 

и все же хочеца как то авторизовать а не слать пакеты на чужой хост после смены айпи 

во первых это не совсем безопасно хоть выше и будет шифрование 

во вторых это будет похоже на ddos 

ну адрес хоста на белом айпи я буду мониторить по ddns ?

а адрес микротика по cloud ip выходит так?

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

или просто планировщиком?

или лучше просто поднимать фиктивный туннель без данных только для проверки второй стороны например на sstp

 

да у меня задача типа смотреть видео  с дачи из дома 

и я предпочту нагородить огород с сетевыми устройствами 

а потом просто подключаца к компу и смотреть 

 

ваши варианты не устраивают:

 

1. создавать из ремукса нарезку по 4гига через virtualdub - ну грозит ошибками, требует точности, не автоматизизированно и вообще убого

2. exfat вобще ни о чем - использует одну копию таблицы fat - да на флешках лучше использовать фс без журналирования - но я б предпочел родную ext3 -4 для линукса или лучше вообще ntfs с ним на винде проще (телефон не рутованный - и не хочу рутить. хз драйвера от парагона будут на нерутованный вставать - да и не известно будет ли прога корректно с ними работать

3. otg без внешнего питания вообще вариант - но копировать на microsd или обычную флешку не вариант - хочеца выбрать и смотреть

4. usb hub otg с внешним питанием и хардом - ну как это будет выглядеть со шлемом виртуальной реальности 

5. внешний хард со своим питанием и wifi смотрица не плохо - типа nas - но опятьже предварительное копирование   - это самый лучший вариант из предложенных вами но уже купил микротик и срок возврата прошел - покупать еще один девайс? да и кидать на него придеца по той-же сети

6. torrent tv - это смотреть не свое а чужое - да и они пытаюца монетизировать доступ - да и сами разрабы ace stream media будут брать плату за превышение  квоты траффика 

resilio не выход тоже 

7. nfs webdav итп хз как они подхватяца этой прогой или будут только для копирования. не говоря уже о экзотике что потребует рута типа ftp mount итп - если вообще возможно под андроидом

 

ps вот отсюда я взял про одну сеть 

https://4pda.ru/forum/index.php?showtopic=257576

Основное требование: Все устройства (один или несколько ПК, Андроиды) должны быть подключены к одной сети!
WD My Cloud - хм думал он с wifi -  не подойдет

 

одноплатные компьютеры типа cubietruck или rasberry pi уже больше похожи на то что нужно если с wifi и питанием 5вольт под powerbank

Изменено пользователем Smirnovi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.