LINUX.ORG.RU

Сообщения sat_art

 

Centos 8, mc, telneat.

Форум — General

Ну люблю я пользоваться этой софтиной. Но возникла проблема. Я всегда коннекчусь к локальному линуксу у которого в локали ru_RU.KOI8-R. И с него соединяясь дальше без проблем все отображалось нормально на 6 7 сентосе и прочих федорах. На centos 8 mc не хочет нормально рисовать рамку. Все время какая то херь. mc -a не предлагать. локали перепробовал в разных вариантах. Ничего не помогает. Понимаю, что что то с настройками xterm. А что именно не въеду. Может подскажет кто, что нужно сделать, что бы мс нормально отображал символы? Речь не о русских буквах, он и в en_US не хочет нормально показывать.

 ,

sat_art
()

Загрузка без видеокарты.

Форум — General

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

 , ,

sat_art
()

Два канала в один гарнтированный.

Форум — Admin

Уже больше года периодами поднимал для себя вопрос как организовать по двум каналам гарантированную доставку трафика.

Все варианты с перебрасыванием маршрутов, переконнектом ОпенВПН при попадании одного и т.д. отбрасывались по причине - это время реакции.

К примеру есть сервер дома, у него два независимых провайдера в инет. И есть сервер, к примеру в германии. Необходимо, что бы пакет пришедший на сервер в Германии попал на домашнюю машину. 100% гарантии никто и никогда конечно не получит, но бывает ситуация, что на основном (используемом в данный момент) канале (админ свич перетыкал) пропадет инет на пару секунд, а для софта это критичное время.

Поэтому решил сам для себя сваять небольшую софтину которую и представляю на ваше рассмотрение.

Исходные данные два сервера, один дома (два канала интернета), второй в Германии два ИП адреса. На одном и на втором сервере запускается dtun (dounle tunnel, так мне захотелось назвать)

dtun [-b][-h]

-b|--bg : start in background, default - none

--s1=ADDRESS : remote server 1 IP, default - 127.0.0.1

--s2=ADDRESS : remote server 2 IP, default - 127.0.0.1

--p1=PORT : remote server 1 Port, default 4444

--p2=PORT : remote server 2 Port, default 4444

--tapN=NUMBER : local tap interface number, default - 0

--tapA=ADDRESS : local tap interface address, default - 192.168.0.1

-h|--help : this help

-b|--bg - заставляет работать в фоне

--s1=ADDRESS первый адрес удаленной машины

--s2=ADDRESS второй адрес удаленной машины

--p1=PORT - порт первого адреса

--p2=PORT - порт второго адреса

--tapN=NUMBER номер локального tap интерфейса

--tapA=ADDRESS адрес локального tap иртерфейса

-h|--help хелп он и в африке хелп.

При запуске поднимается tap интерфейс и все приходящие на него пакеты будут отсылаться по udp протоколу на два адреса удаленного сервера. На удаленной стороне точно так же. Все приходяшие на локальный порт пакеты транслируются в локальный tap интерфейс. Дублирующий пакет (пришедший по второму каналу) просто игнорируются.

Исходники и скомилированный под х64 бинарик тут Здесь

Пример запуска

/dtun/dtun --lport 5001 --s1 21.22.23.24 --s2 21.22.23.25 --p1 5001 --p2 5001 --tapN 1 --tapA 192.168.2.1 -b

Пока конечно все сыро - поэтому сильно не пинайте, но работает и приносит пользу.

Для тех кто будет ковырять исходники. Пока нет проверки порядка прихода пакета, они конечно же нумеруются. Но все пакеты попадают в буфер. В дальнейших планах сделать проверку очередности и контроль. (Хотя особого смысла наверное не будет).

Отсылаемые пакеты пакуются lzo - поэтому перед компиляцией установите lzo-devel - есть ли смысл, пока не знаю, немного грузит проц. За основу взяты исходники простого туннеля, найденные не помню даже где, самому писать тяжеловато. Сам в сях я не очень, но как говорится если надо то надо. Поэтому сильно не пинайте. Может, наоборот, кто то доделает по уму, думаю многим пригодится. Обмен построен на udp по принципу отправил и забыл. То есть нет понятия нормального соединения, когда один сервер с реальным ИП а второй за натом, просто так работать не будут, для второго надо пробрасывать порт с файрвола. Это с одной стороны минус, а с другой нет понятия никаких таймаутов. Т.е. если сервер за натом то соответственно он должен инициировать соединение и необходимо его контролировать. Здесь же пакеты просто уходят по назначению и все. Контроль уже ложится например на ТСП соединение которое строится по этому туннелю. Наверное так.

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

sat_art
()

RSS подписка на новые темы