Маю цікаву ідею сервісу для проксірування трафіку 🚀💻. Детально розпишу у статті або статтях 📝, інформації для вивчення там немало, а тут опишу суть.
А суть в тому, що помітив, що іноді DNS-трафік летить напряму до резолвера, незважаючи на те, що я намагаюся використовувати проксі 🌐. Ця ситуація повторюється і якщо використовувати проксі напряму через CLI-інструменти, і навіть якщо використовувати через proxychains чи проксі-брокери. Погуглив і зрозумів, що проблема відома і є декілька варіантів її вирішити 🔍.
Варіанти є, а готового безкоштовного рішення нема. Непорядок 😤. Буду виправляти!
Підніму шлюз з кастомною логікою проксіювання запитів. 🖥
Також прийшла в голову ідея автоматично збирати проксі, перевіряти і ранжувати їх під капотом, не перекладаючи цей процес на плечі користувача.
Логіка зрозуміла. Детальніше буде у статті 📄 і в наступних постах.
А суть в тому, що помітив, що іноді DNS-трафік летить напряму до резолвера, незважаючи на те, що я намагаюся використовувати проксі 🌐. Ця ситуація повторюється і якщо використовувати проксі напряму через CLI-інструменти, і навіть якщо використовувати через proxychains чи проксі-брокери. Погуглив і зрозумів, що проблема відома і є декілька варіантів її вирішити 🔍.
Варіанти є, а готового безкоштовного рішення нема. Непорядок 😤. Буду виправляти!
Підніму шлюз з кастомною логікою проксіювання запитів. 🖥
Також прийшла в голову ідея автоматично збирати проксі, перевіряти і ранжувати їх під капотом, не перекладаючи цей процес на плечі користувача.
Логіка зрозуміла. Детальніше буде у статті 📄 і в наступних постах.
🤯1🤝1
Як я зрозумів, що проблема є? 🤔
Розкажу, що саме сталось 📝.
Запустив whatweb із заданим параметром проксі і одразу отримав відмову 🛑. Спершу не зрозумів, у чому справа — просто щось не спрацювало. Почав розбиратись і зрозумів: тула в обхід налаштувань проксі сама йшла до DNS напряму — минаючи проксі повністю. Але я для того проксі й накинув, щоб звертатись не напряму 🔄. А без проксі цей запит просто не відпрацював. Так стало зрозуміло, що маю справу з витоком🫣 .
Обійти це я спробував через proxychains, але й тут виникла проблемка, whatweb всеодно слав запити напряму, ігноруючи мої налаштування ❌.
Я зрозумів, що так може зробити не тільки whatweb, а будьяка інша тула і спробуй вгадай яка і в який момент вирішить мене спалить 💔.
А отже, якщо є проблема, то потрібно знайти для неї вирішення, щоб зберегти баланс у всесвіті ⚖️.
Я вирішив, якщо в системі мої налаштування проксі може обійти будь-яка тулза, то я буду ловити їх запити поза системою і акуратно загортати у проксікі, так як мені потрібно 🛡.
Отака ідея 💡.
Далі я пішов шукати готові рішення 🔍.
Про те, що я знайшов, буду писати далі ✍️.
Розкажу, що саме сталось 📝.
Запустив whatweb із заданим параметром проксі і одразу отримав відмову 🛑. Спершу не зрозумів, у чому справа — просто щось не спрацювало. Почав розбиратись і зрозумів: тула в обхід налаштувань проксі сама йшла до DNS напряму — минаючи проксі повністю. Але я для того проксі й накинув, щоб звертатись не напряму 🔄. А без проксі цей запит просто не відпрацював. Так стало зрозуміло, що маю справу з витоком
Обійти це я спробував через proxychains, але й тут виникла проблемка, whatweb всеодно слав запити напряму, ігноруючи мої налаштування ❌.
Я зрозумів, що так може зробити не тільки whatweb, а будьяка інша тула і спробуй вгадай яка і в який момент вирішить мене спалить 💔.
А отже, якщо є проблема, то потрібно знайти для неї вирішення, щоб зберегти баланс у всесвіті ⚖️.
Я вирішив, якщо в системі мої налаштування проксі може обійти будь-яка тулза, то я буду ловити їх запити поза системою і акуратно загортати у проксікі, так як мені потрібно 🛡.
Отака ідея 💡.
Далі я пішов шукати готові рішення 🔍.
Про те, що я знайшов, буду писати далі ✍️.
Please open Telegram to view this post
VIEW IN TELEGRAM
Останній тиждень просто скажений 😵💫.
Розгортаю нову ноду для прикольних нових проектів 🚀.
Збираю онлайн платформу для того, щоб збирати свої думки в одному місці 🧠.
І реалізую новий проект прозорого проксі 🔍. Перші версії вже викладені на github 💻.
Перша частина статті, де я розповім детальніше про проблему і підхід до її вирішення вже на підході ✍️.
💪
Розгортаю нову ноду для прикольних нових проектів 🚀.
Збираю онлайн платформу для того, щоб збирати свої думки в одному місці 🧠.
І реалізую новий проект прозорого проксі 🔍. Перші версії вже викладені на github 💻.
Перша частина статті, де я розповім детальніше про проблему і підхід до її вирішення вже на підході ✍️.
Please open Telegram to view this post
VIEW IN TELEGRAM
DNS leak за кілька хвилин 🕵️
Проксі налаштували, а DNS точно йде через нього? 🤔
Я для себе перевіряю це просто через tcpdump 🔍.
На машині, де крутиться тула, запускаю:
Потім у другому вікні роблю звичайний запит через інструмент, який нібито працює через проксі 🌐.
Якщо в tcpdump видно пакети до 8.8.8.8:53, 1.1.1.1:53 або системного resolver — DNS іде напряму 🫣
Тобто HTTP-запит може піти через проксі, а домен, до якого ви звертаєтесь, уже засвітився назовні ⚠️.
Саме так я й знайшов проблему з WhatWeb.
У наступному пості покажу, чому proxychains не завжди рятує від цього 😬 ✍️
Проксі налаштували, а DNS точно йде через нього? 🤔
Я для себе перевіряю це просто через tcpdump 🔍.
На машині, де крутиться тула, запускаю:
tcpdump -ni any port 53
Потім у другому вікні роблю звичайний запит через інструмент, який нібито працює через проксі 🌐.
Якщо в tcpdump видно пакети до 8.8.8.8:53, 1.1.1.1:53 або системного resolver — DNS іде напряму 🫣
Тобто HTTP-запит може піти через проксі, а домен, до якого ви звертаєтесь, уже засвітився назовні ⚠️.
Саме так я й знайшов проблему з WhatWeb.
У наступному пості покажу, чому proxychains не завжди рятує від цього 😬 ✍️
Чому Proxychains не гарантує проксіювання DNS 🔄
Після того як WhatWeb почав ходити до DNS напряму, я подумав: ну ок, є ж proxychains 🤷♂️
Але в моєму випадку картина не змінилась ❌.
proxychains добре працює там, де може перехопити мережевий виклик самої програми. Але DNS може оброблятись окремо: через системний resolver, бібліотеку, кеш або інший механізм, який не потрапляє під його контроль 🔍.
Тобто логіка «обгорнув тулу в proxychains — значить усе анонімно» небезпечна ⚠️
Будь-яка програма може:
• зарезолвити домен напряму;
• використати нестандартний механізм DNS;
• просто помилитися в реалізації;
• або в якийсь момент обійти ваші налаштування.
Тому я вирішив контролювати DNS не всередині конкретної тули, а на рівні gateway 🛡 🌐
Далі покажу схему, до якої в підсумку прийшов.
Після того як WhatWeb почав ходити до DNS напряму, я подумав: ну ок, є ж proxychains 🤷♂️
Але в моєму випадку картина не змінилась ❌.
proxychains добре працює там, де може перехопити мережевий виклик самої програми. Але DNS може оброблятись окремо: через системний resolver, бібліотеку, кеш або інший механізм, який не потрапляє під його контроль 🔍.
Тобто логіка «обгорнув тулу в proxychains — значить усе анонімно» небезпечна ⚠️
Будь-яка програма може:
• зарезолвити домен напряму;
• використати нестандартний механізм DNS;
• просто помилитися в реалізації;
• або в якийсь момент обійти ваші налаштування.
Тому я вирішив контролювати DNS не всередині конкретної тули, а на рівні gateway 🛡 🌐
Далі покажу схему, до якої в підсумку прийшов.
Схема Transparent Gateway 🗺
Поступово в голові склалась така конструкція 🧠.
Є робоча VM. Їй не потрібно знати, як саме працює проксіювання, які проксі зараз живі та через який resolver відправляти DNS.
Вона просто працює 🌐
А gateway уже ловить і маршрутизує трафік ⚙️:
Головна думка: не довіряти кожній окремій тулі 🔍.
Якщо програма може відправити DNS не туди, куди потрібно, gateway має це побачити й перехопити. Інакше достатньо одного невдалого запиту, щоб засвітити реальний маршрут 😶🌫️
Наступний крок — розділити звичайні DNS-запити й запити до конкретних resolver 🚀.
Поступово в голові склалась така конструкція 🧠.
Є робоча VM. Їй не потрібно знати, як саме працює проксіювання, які проксі зараз живі та через який resolver відправляти DNS.
Вона просто працює 🌐
А gateway уже ловить і маршрутизує трафік ⚙️:
Робоча VM → gateway
TCP → redsocks → HAProxy → upstream → Internet
DNS →
стандартний запит → DoH → resolver
запит до конкретного resolver → UDP-to-TCP → resolver
Головна думка: не довіряти кожній окремій тулі 🔍.
Якщо програма може відправити DNS не туди, куди потрібно, gateway має це побачити й перехопити. Інакше достатньо одного невдалого запиту, щоб засвітити реальний маршрут 😶🌫️
Наступний крок — розділити звичайні DNS-запити й запити до конкретних resolver 🚀.
DoH, UDP-to-TCP і два маршрути для DNS 🔀
Не весь DNS однаковий 🤔.
У більшості випадків мені неважливо, який саме resolver поверне IP-адресу. Такі запити можна завернути в DoH: вони шифруються та виходять із gateway контрольованим шляхом 🔒
Але іноді треба звернутись до конкретного resolver, наприклад до 8.8.8.8 🌐.
Тут DoH не завжди підходить: конкретний DNS-сервер може не підтримувати його або потрібна саме його відповідь.
Тому в gateway є дві гілки 🔀:
• DNS на стандартні адреси → локальний DoH relay;
• DNS на конкретну адресу → перехоплення через TPROXY → UDP-to-TCP relay → потрібний resolver.
Так запит від програми виглядає для неї звичайним UDP DNS, але gateway сам вирішує, як доставити його далі 🛡 ⚙️ 🚀
Далі — трохи магії iptables і TPROXY.
Не весь DNS однаковий 🤔.
У більшості випадків мені неважливо, який саме resolver поверне IP-адресу. Такі запити можна завернути в DoH: вони шифруються та виходять із gateway контрольованим шляхом 🔒
Але іноді треба звернутись до конкретного resolver, наприклад до 8.8.8.8 🌐.
Тут DoH не завжди підходить: конкретний DNS-сервер може не підтримувати його або потрібна саме його відповідь.
Тому в gateway є дві гілки 🔀:
• DNS на стандартні адреси → локальний DoH relay;
• DNS на конкретну адресу → перехоплення через TPROXY → UDP-to-TCP relay → потрібний resolver.
Так запит від програми виглядає для неї звичайним UDP DNS, але gateway сам вирішує, як доставити його далі 🛡 ⚙️ 🚀
Далі — трохи магії iptables і TPROXY.
TPROXY: як не дати DNS пройти повз gateway ⚙️
Для перехоплення DNS я використовую окремі ланцюжки iptables ⚙️.
Логіка проста:
1. Ловимо UDP-пакети на порт 53 від тестової підмережі.
2. Запити до стандартних resolver відправляємо на локальний DoH relay.
3. Усе інше перехоплюємо через TPROXY і передаємо у UDP-to-TCP relay 🛡.
Схематично 🔍:
Після цього треба ще додати ip rule і локальний route для позначених пакетів — без цього TPROXY не доставить їх у потрібний socket ✅.
Повний розбір із кодом, схемою та перевірками вже виклав у статті 📄:
https://devdays.net.ua/articles/vitik-dns-abo-buduiemo-velosiped/
Наступною частиною покажу саме проксіювання TCP-трафіку через gateway 🚀 💻
Для перехоплення DNS я використовую окремі ланцюжки iptables ⚙️.
Логіка проста:
1. Ловимо UDP-пакети на порт 53 від тестової підмережі.
2. Запити до стандартних resolver відправляємо на локальний DoH relay.
3. Усе інше перехоплюємо через TPROXY і передаємо у UDP-to-TCP relay 🛡.
Схематично 🔍:
# Стандартний DNS → DoH relay
iptables -t nat -A TG_DNS_DOH \
+ -p udp -d 1.1.1.1 --dport 53 \
+ -j REDIRECT --to-ports 5053
# Інший DNS → UDP-to-TCP relay
iptables -t mangle -A TG_DNS_TPROXY \
+ -p udp --dport 53 \
+ -j TPROXY --on-ip 127.0.0.1 --on-port 5353 \
+ --tproxy-mark 0x1/0x1
Після цього треба ще додати ip rule і локальний route для позначених пакетів — без цього TPROXY не доставить їх у потрібний socket ✅.
Повний розбір із кодом, схемою та перевірками вже виклав у статті 📄:
https://devdays.net.ua/articles/vitik-dns-abo-buduiemo-velosiped/
Наступною частиною покажу саме проксіювання TCP-трафіку через gateway 🚀 💻
Дійшов до звичайного TCP-трафіку 🌐
З DNS розібрались, а отже настав час проксувати все інше ⚙️
Спочатку хотів налаштовувати проксі в кожній окремій тулі. Але швидко зрозумів, що це шлях у нікуди 😬
Одна програма підтримує SOCKS, інша — тільки HTTP, а третя взагалі вирішить піти напряму. Стежити за кожною окремо мені не хотілось.
Тому логіку виніс на gateway:
Робоча VM просто відкриває TCP-з’єднання. Вона не знає, який проксі зараз живий і через кого насправді піде трафік. Усю цю кухню бере на себе Transparent Gateway 🛡
Наступним кроком треба було зробити так, щоб VM фізично не могла обійти gateway.
Посиланя на гітхаб проекту додав нижче, якщо комусь цікаво розібратись як все працює під капотом, або прийняти участь у рощзробці.
https://github.com/Va1b0rt/TransparentGateway
З DNS розібрались, а отже настав час проксувати все інше ⚙️
Спочатку хотів налаштовувати проксі в кожній окремій тулі. Але швидко зрозумів, що це шлях у нікуди 😬
Одна програма підтримує SOCKS, інша — тільки HTTP, а третя взагалі вирішить піти напряму. Стежити за кожною окремо мені не хотілось.
Тому логіку виніс на gateway:
VM → iptables → redsocks → HAProxy → proxy → host
Робоча VM просто відкриває TCP-з’єднання. Вона не знає, який проксі зараз живий і через кого насправді піде трафік. Усю цю кухню бере на себе Transparent Gateway 🛡
Наступним кроком треба було зробити так, щоб VM фізично не могла обійти gateway.
Посиланя на гітхаб проекту додав нижче, якщо комусь цікаво розібратись як все працює під капотом, або прийняти участь у рощзробці.
https://github.com/Va1b0rt/TransparentGateway
GitHub
GitHub - Va1b0rt/TransparentGateway
Contribute to Va1b0rt/TransparentGateway development by creating an account on GitHub.