Как можно заходить на RDP не ожидая супер-медленный прогруз 1 вкладки 5 секунд? Но при этом хочется чтобы безопасность до подключения была на достойном уровне. Подключаться к RDP без TOR, конечно не вариант, если вскроют RDP - цепочка до RDP должна быть не такой простой, ведь если до RDP у тебя особо нет ничего, то анонимность ставится под угрозу. Не закрывать TOR VPN? Но если будут слушать выходную TOR ноду и не будет VPN на конце - это тоже не очень. Какой вариант самый идеальный? Вот локбиты всякие например же подключаются по RDP, и как? Он хорошо относится к своей безопасности и при этом сидит на RDP, есть догадки что он может делать чтобы скорость была приемлимой?
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Безопасное и не слишком медленное подключение к RDP
- Автор темы cryptoapple
- Дата начала
Слушай, твои вопросы уже заели на форуме, и каждый раз - одна и та же каша в голове. Прежде чем лезть в дебри цепочек VPN-Tor-VPN-RDP и рассуждать про "локбитов", давай ты с базой разберешься?
Допустим, какой latency требует RDP, а как её генерирует Tor по своей природе. Это физика сетей и протоколов, тут нет ничего личного. И твой "уровень" анонимности - это не повторение цепочек Tor+VPN++, а прежде всего OpSec, который у тебя, судя по вопросам, на нуле.
Те "локбиты" не сидят "на RDP" так, как ты себе это представляешь. У них своя, выстроенная инфраструктура: цепочки из своих и ломаных тачек, левых и арендованных VPS, приватных туннелей разного типа, проксей (с обфускацией и без). Да, там могут быть и SSH, и RDP, и VPN, и тот же Tor (как публичный, так и свой) и много еще чего - но всё это вплетено в сложную схему под конкретную задачу, и не тупо для интерактивной работы, как нужно тебе.
У них есть ресурсы, понимание и задача. С ними ясно. А ты? Почему шифруешься так неумело, пытаясь пропихнуть RDP через самые медленные и заведомо палевные (для такой активности) публичные каналы? Твоя модель угроз какая?
Если ты оператор наркошопа - хочу тебя сразу огорчить, тебя точно нахватят...
Твоя проблема - не в поиске "идеальной" схемы (её нет для твоих хотелок), а в фундаментальном непонимании основ компьютерных сетей. Что такое TCP/IP, latency, bandwidth, как реально устроен Tor, чем VPN отличается от прокси или туннеля и т.д. А главное - что такое OpSec, и почему он на порядок важнее твоих кривых цепочек!
Пока в голове нет этой базы - ты так и будешь лепить нерабочих монстров, задавать кринжовые вопросы на форуме и получать закономерный результат: боль, тормоза и - хуже всего - ложное чувство безопасности.
Допустим, какой latency требует RDP, а как её генерирует Tor по своей природе. Это физика сетей и протоколов, тут нет ничего личного. И твой "уровень" анонимности - это не повторение цепочек Tor+VPN++, а прежде всего OpSec, который у тебя, судя по вопросам, на нуле.
Те "локбиты" не сидят "на RDP" так, как ты себе это представляешь. У них своя, выстроенная инфраструктура: цепочки из своих и ломаных тачек, левых и арендованных VPS, приватных туннелей разного типа, проксей (с обфускацией и без). Да, там могут быть и SSH, и RDP, и VPN, и тот же Tor (как публичный, так и свой) и много еще чего - но всё это вплетено в сложную схему под конкретную задачу, и не тупо для интерактивной работы, как нужно тебе.
У них есть ресурсы, понимание и задача. С ними ясно. А ты? Почему шифруешься так неумело, пытаясь пропихнуть RDP через самые медленные и заведомо палевные (для такой активности) публичные каналы? Твоя модель угроз какая?
Если ты оператор наркошопа - хочу тебя сразу огорчить, тебя точно нахватят...
Твоя проблема - не в поиске "идеальной" схемы (её нет для твоих хотелок), а в фундаментальном непонимании основ компьютерных сетей. Что такое TCP/IP, latency, bandwidth, как реально устроен Tor, чем VPN отличается от прокси или туннеля и т.д. А главное - что такое OpSec, и почему он на порядок важнее твоих кривых цепочек!
Пока в голове нет этой базы - ты так и будешь лепить нерабочих монстров, задавать кринжовые вопросы на форуме и получать закономерный результат: боль, тормоза и - хуже всего - ложное чувство безопасности.
Последнее редактирование:
- Автор темы
- Добавить закладку
- #5
Про опсек настолько очевидно что про это даже не имеет смысла говорить. Мне нравится что ты понял уровень моих знаний безопасности по вопросу как можно заходить на сервер после цепочки впн-тор-впн. Я знаю что такое тор и знаю что такое впн, знаю что такое тунель) Может ты предлагаешь мне изучить процессы создания архитектуры компьютера чтобы понимать как происходит включение процессора? Мой вопрос состоит не в том чтобы найти чудо-цепочку, а в том как ускорить соединение. Чем плох публичный тор? Везде есть свои нюансы и нужно понимать какие могут быть недостатки в том же торе, и эффективно устранять их. Как ты можешь понять уровень моего понимания в безопасности и построения цепочек по вопросу как ускорить подключение? С чего ты взял что впн-тор-впн это нерабочая связка? Откуда ты знаешь что локбиты не сидят на RDP в том контексте как я себе это представляю?) В чем кринжовость вопроса как ускорить соединение к RDP? Что значит шифруюсь неумело пытаясь пропихнуть RDP через публичные и медленные каналы? Конкретизируй что конкретно тут плохо и предложи лучшую по твоему мнению альтернативу) Заходить на RDP через тор и впн это неумелая шифровка по открытым и публичным каналам? Мне уже интересно, что ты предложишь взамен)
К серверу можно подключаться через тор легко, и все будет работать должным образом, в твоем понимании не существует ни одного человека который подключался бы к серверу через тор? Жду твою альтернативу которая будет намного эффективнее и лучше, а главное быстрее.
Последнее редактирование:
Да тебе в целом по делу сказали, вот тебе спека от майков - https://learn.microsoft.com/ru-ru/azure/virtual-desktop/rdp-bandwidth на нее и ориентируйся, в первую очередь разберись с BW, а потом уже строй цепочки с нужными гео, чтобы в адекватный latency влезть.
P.S. Если у тебя на выходе будет меньше 5 мбит и/или пинга в космосе будет - получишь слайдшоу.
- Автор темы
- Добавить закладку
- #7
Вот это полезный ответ, дающий нужную информацию. Благодарю. Все что нужно было знать.