ReverseTlsTunnel
ReverseTlsTunnel copied to clipboard
radkesvat
راه حل موقت برای رفع مشکل کندی و پر شدن رم و سی پی یو
سلام دوستان کسانی که تعداد کاربر خیلی بالایی دارن احتمالا به مشکل بخورن توی هندل کردن درخواست ها البته طبق تست هایی که داشتم این داستان زیاد ربطی به RTT نداره . هرچند شاید بشه تا بهینه کردن کد ها و اضافه شدن Multithreading به RTT این مشکل رو حل کرد ولی بازم من مطمئن هستم که به مشکل میخوره بزارید کامل براتون توضیح بدم که متوجه بشید چرا بازم به مشکل میخوره
با توجه به اینکه بنده دانش فنی و تسلط کافی در بحث لینوکس و شبکه رو ندارم ممکن هست بعضی از گفته های بنده اشتباه باشه که پیشاپیش از شما معذرت میخوام و از اساتید محترم میخوام که بنده رو اصلاح کنن و مشکلات رو بگید که ویرایش کنم
اگر حوصله ندارید و کلا براتون مهم نیست که درک کنید مشکل چیه و چطوری حل میشه مقدمه رو نخونید .مستقیم برید راه حل رو بخونید
تمامی کد های زیر رو باید در سرور ایران اجرا کنید . البته بخش بهینه سازی رو میتونید در سرور خارج هم اجرا کنید
مقدمه و درک مشکل
من خودم از sing-box استفاده میکنم . حالت Multithreading همین الان هم داخل ساین باکس هست یعنی شما 1 بار ساین باکس رو اجرا میکنی ولی اون خودش میاد چندین پراسس دیگه که میشه child process رو اجرا میکنه چرا این کار رو میکنه ؟ برای اینکه بتونه بهتر مدیریت کنه درخواست ها رو و درخواست های ورودی رو بین چندین پراسس پخش میکنه تا هندل بشن و مثلا اگر شما 2 تا هسته داری از توان هر 2 هسته cpu شما استفاده بشه حالا چرا برنامه ها از حالت Multithreading پشتیبانی نمیکنن ؟ چون پیاده سازی همچین چیزی به این راحتی ها نیست و مدیریت کردن انجام شدن درخواست ها به صورت موازی یکم پیچیده هست که از دانش من هم خارج هست صرفا طبق چیز هایی که مطالعه کردم میدونم که سخت هست خب گفتیم که ساین باکس برای هندل کردن درخواست ها از چندین ترد که ایجاد کرده استفاده میکنه ولی بازم وقتی تعداد درخواست بالا میره به مشکل میخوره ساین باکس و نمیتونه مدیریت کنه اینکه چرا اینطوری میشه رو من دقیق نمیدونم شاید به خاطر این باشه که سیستم عامل بهش اجازه نمیده و یا محدودیت های نرم افزاری باشه یا چیز های دیگه در هر صورت من این راه حل به ذهنم رسید که بیام و به جای 1 ساین باکس چندین ساین باکس اجرا کنم و درخواست ها رو بین اینا پخش کنم حالا شما فرض کن خود ساین باکس هم ترد داره و اینطوری شما یه لود بالانس دستی درست کردی که یه تعداد زیادی ترد اماده هستن به درخواست های شما جواب بدن :) اینم بگم که این روش به این خاطر به ذهن من رسید که دیدم درصد استفاده از منابع سرور اصلا بالا نرفتن ولی وقتی درخواست ها زیاد میشه ساین باکس دیگه جواب نمیده . اینجا خب فکر کردم شاید محدودیت نرم افزاری باشه و اگر چند تا ساین باکس اجرا کنیم مشکل حل بشه که همین طور هم شد سرور من 8 گیگ رم و 2 تا هسته فرکانس 5.7 داره که به این راحتی پر نمیشه ولی جالب بود که با این همه منابع بازم ساین باکس به مشکل میخورد این نشون میده که کد هاش یا بهینه نیست یا درست نمیتونه از منابع سیستم استفاده کنه حالا شاید بگید چطوری فهمیدم که مشکل از RTT نیست و از ساین باکس هست ؟ من اومدم یک socks داخل ساین باکس تعریف کردم روی پورت مثلا 1080 روی 127 تا تست کنم اصلا ساین باکس میتونه به درخواست های داخلی جواب بده یا نه . چ برسه به درخواست هایی که از سرور ایران براش میاد
بعدش کد زیر رو برای تست اجرا کردم
curl --socks5-hostname 127.0.0.1:1080 http://ip-api.com/
که خب تایم اوت میخورد این یعنی ساین باکس اصلا توان هندل یه درخواست داخلی هم نداشت و مشکل از RTT نیست پس بهترین کار این هست که چند تا ساین باکس اجرا کنیم و یه طوری حل کنیم این مشکل رو حالا این راه حل رو میشه برای بقیه برنامه ها هم زد . مثل RTT یا هر چیز دیگه
برای درک بهتر به عکس بالا دقت کنید که . بخش سفید رنگ ساین باکس هست که ران شده و اون سبز ها ترد هاش هستن حالا عکس زیر رو دقت کنید
این عکس هم مربوط به RTT هست که همین طور که مشاهده میکنید چون هنوز از ترد پشتیبانی نمیکنه هیچ تردی نداره و خودش همه درخواست ها رو با استفاده از 1 هسته cpu هندل میکنه . یعنی ممکن هست شما 4 تا هسته داشته باشی ولی RTT فقط از 1 هسته cpu شما استفاده میکنه اینطوری همه فشار روی 1 هسته هست و از تمام توان cpu شما استفاده نمیشه حالا فرض کنیم که RTT اپدیت بده و مثل ساین باکس ترد بهش اضافه بشه . به احتمال زیاد مشکل به صورت موقت حل میشه ولی امکان داره اون مشکل که برای ساین باکس گفتم برای RTT هم پیش بیاد یعنی حتی با وجود ترد امکان داره که درخواست ها بازم در ابعاد بالا به مشکل بخورن پس این راه حل که میگم میتونه یه راه حل خوبی باشه که شما بتونی تعداد کاربر بالا رو با این روش هندل کنید و کاربران هم به مشکل نخورن
راه حل
خب بریم سراغ راه حل . چیزی که من به ذهنم اومد این بود که RTT رو چندین بار اجرا کنیم تا اینطوری خودمون دستی حالت ترد رو پیاده سازی کرده باشیم ولی خب یه مشکلی که پیش میاد این هست که چندین برنامه نمیتونن به صورت هم زمان از یک پورت مثلا 443 استفاده کنن یعنی فرض کن شما توی سرور ایران به RTT گفتی که به 443 لسن کنه وقتی بخوای 4 تا RTT اجرا کنی دیگه نمیشه هر 4 تا از 443 لسن کنن و هر RTT باید از یک پورت جدا لسن کنه که اینجا برای حل این مشکل از haprpxy استفاده میکنیم . این haproxy یه برنامه قوی برای درست کردن لود بالانس هست . حالا این یعنی چی ؟ شما فرض کن من میخوام RTT رو 4 بار اجرا کنم . میام این 4 تا رو روی پورت های مختلف اجرا میکنم . مثلا پورت های زیر : 1010 2020 3030 4040 بعدش به haproxy میگم تو روی 443 لسن کن و هر درخواستی که به 443 اومده بین این 4 تا RTT پخش کن . به همین سادگی ! خب شاید بگید که الان مشکل RTT و ساین باکس برای haproxy چرا پیش نمیاد ؟ یعنی ممکن هست این وسط haproxy هم هنگ کنه و نتونه درخواست ها رو هندل کنه ولی خب اینطوری نیست چون haproxy یه برنامه قدیمی هست که اصلا کارش مدیریت کردن تعداد درخواست بالا هست و ساخته شده برای اینکار و طوری طراحی شده که کم نمیاره
بهینه سازی سرور
قبل از اینکه شروع کنیم چند تا کد زیر رو اجرا کنید که بتونید از تمامی توان نرم افزاری و سخت افزاری سرور استفاده کنید چون پیشفرض خیلی از چیز ها محدود هست . اگر نیاز بود بگید توضیح بدم که کد های زیر دقیقا چیکار میکنن ولی یه توضیح کوچیک زیر هر کدوم میدم .
این کد برای این هست که به سیستم بگیم اگر حجم log ها بیشتر از 10 مگ شد لاگ ها رو پاک کنه . اینطوری دیگه فضای سرور اگر مشکلی پیش بیاد پر نمیشه به خاطر لاگ
sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=10M/' /etc/systemd/journald.conf && sudo systemctl restart systemd-journald
این کد هم برای بهینه کردن شبکه TCP هست . دقت کنید که من در 2 خط اخر ipv6 رو کلا غیر فعال کردم اگر به ipv6 نیاز دارید 2 خط اخر رو حذف کنید
sudo echo ' fs.file-max = 1048576 fs.inotify.max_user_instances = 1048576 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.core.netdev_max_backlog=2000 net.ipv4.tcp_rmem = 8192 262144 536870912 net.ipv4.tcp_wmem = 4096 16384 536870912 net.ipv4.tcp_adv_win_scale = -2 net.ipv4.tcp_collapse_max_bytes = 6291456 # forward ipv4 net.ipv4.ip_forward = 1 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_keepalive_time = 90 net.ipv4.tcp_congestion_control=bbr net.core.default_qdisc=cake net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 ' > /etc/sysctl.conf
اینجا به سرور میگیم که کلا هیچ محدودیت برای nofile و nproc قرار نده و از حداکثر توان سرور استفاده کنه
sudo mkdir /etc/systemd/system.conf.d sudo echo '[Manager] DefaultLimitNOFILE=infinity' > /etc/systemd/system.conf.d/99-unlimited.conf sudo echo 'session required pam_limits.so' >> /etc/pam.d/common-session sudo echo 'session required pam_limits.so' >> /etc/pam.d/common-session-noninteractive sudo echo '* hard nofile unlimited * soft nofile unlimited * hard nproc unlimited * soft nproc unlimited root hard nofile unlimited root soft nofile unlimited root hard nproc unlimited root soft nproc unlimited' > /etc/security/limits.conf sudo echo '* hard nofile unlimited * soft nofile unlimited * hard nproc unlimited * soft nproc unlimited root hard nofile unlimited root soft nofile unlimited root hard nproc unlimited root soft nproc unlimited' > /etc/security/limits.d/99-unlimited.conf
برای اینکه کد های بالا اعمال بشن باید یه بار سیستم رو ریبوت کنید
reboot
بعد از اینکه سیستم ریبوت شد اگر درست انجام داده باشید با زدن دستور زیر باید یه عدد بزرگ مثل 1048576 رو نشون بده . اگر 1024 نشون داد یعنی یه جا اشتباه کردید و از اول انجام بدید دوباره .
ulimit -n
پیاده سازی haproxy
دستور نصب haproxy
sudo apt install --no-install-recommends software-properties-common -y sudo add-apt-repository ppa:vbernat/haproxy-2.8 -y sudo apt update sudo apt install haproxy -y
اینم کانفیگ haproxy هست که بهش گفتیم به 443 گوش بده و درخواست ها رو بین 4 تا RTT که روی پورت های 1010 تا 4040 تنظیم شدن تقسیم کن . در ادامه بیشتر توضیح میدم
echo ' global nbthread 2 cpu-map 1-2 0-1 maxconn 500000 tune.bufsize 49152 daemon defaults mode http option tcp-check option redispatch option dontlognull option abortonclose option http-keep-alive option http-pretend-keepalive timeout connect 5000 timeout client 50000 timeout server 50000 retry-on all-retryable-errors listen RTT-Threads bind 0.0.0.0:443 balance static-rr server s1 127.0.0.1:1010 check inter 2s server s2 127.0.0.1:2020 check inter 2s server s3 127.0.0.1:3030 check inter 2s server s4 127.0.0.1:4040 check inter 2s ' > /etc/haproxy/haproxy.cfg
اینجا هم سروسی haproxy رو ران میکنیم و تنظیم میکنیم که با ری استارت شدن سرور خودکار اجرا میشه
systemctl enable haproxy systemctl restart haproxy
کد بالا چند تا پارامتر مهم داره .
پارامتر nbthread تعداد ترد هایی هست که haproxy ایجاد میکنه تا بتونه درخواست ها رو جواب بده . بهتر هست مقدارش با تعداد هسته cpu هایی که دارید یکسان باشه . مثلا اگر 2 هسته دارید این هم 2 قرار بدید
پارامتر cpu-map هم مشخص میکنه هر ترد به کدوم هسته از cpu متصل بشه در پارامتر قبلی چون 2 تا ترد تنظیم کردیم پس 2 تا مپ هم میکنیم یعنی میگیم ترد 1 رو به هسته 0 متصل کن و ترد 2 رو به هسته 1 . سیستم عامل هسته ها رو از 0 شروع میکنه
پارامتر maxconn خیلی مهم هست . این رو بر اساس توان شبکه و سرور خودتون کم و زیاد کنید . من قرار دادم که به 500 هزار درخواست بتونه جواب بده . که تعداد خیلی بالایی هست. شما میتونید این مقدار رو کم یا زیاد کنید ولی پیشنهاد میکنیم همون 500 بزارید باشه . شاید بگید اگر از 500 هزار تا بیشتر شد چیکار میکنه ؟ سادش میشه اینکه میاد درخواست ها رو داخل pool قرار میده یعنی یه delay ایجاد میشه تا وقتی که درخواست های قبلی انجام بشن و فضا برای انجام درخواست های جدید باز بشه . یه حالت صف تشکیل میده
یه بخش bind هم داره که گفیتم به پورت 443 گوش بده و در خط های بعدی هم اومدیم RTT ها رو اضافه کردیم که من 4 تا اضافه کردم شما میتونید بیشتر اضافه کنید
نکته جالب اینکه میتونید بهش بگید درخواست ها رو فقط به RTT هایی ارسال کنه که up هستن یعنی اگر یک RTT به هر دلیلی براش مشکل پیش بیاد درخواست رو به RTT های دیگه ارسال میکنه . دقت کنید یه 2s زدم یعنی هر 2 ثانیه چک کنید این RTT کار میکنه یا نه اگر کار نکنه برای یه مدت از لیست حذفش میکنه و درخواست رو به RTT های دیگه ارسال میکنه خوبی این مورد برای وقتی هست که شما RTT ها رو ری استارت کردید و برای چند لحظه کوچیک درخواست ها drop میشن و کاربر لگ میخوره ولی با این قابلیت تا حد زیادی این لگ رفع میشه به این نکته هم دقت کنید که در ادامه ما تنظیم میکنیم که سرویس RTT هر یه مدت ری استارت بشه تا مشکل رم که پرم میشه حل بشه حالا اینجا یه مشکل پیش میاد . اگر ما هر 4 تا RTT رو هم زمان ری استارت کنیم پس 4 تا RTT که تنظیم کردیم down میشن و درخواست ها drop میشن برای چند لحظه پس باید هر RTT رو با یک فاصله زمانی متفاوت ری استارت کنید تا همیشه حداقل یک RTT وجود داشته باشه که به درخواست ها جواب بده اگر یک RTT ری استارت بشه خود haproxy میاد کاربران قدیمی رو به RTT بعدی منتقل میکنه . خیلی زیباست مگه نه ؟
تنظیم RTT ها
خب الان وقت این هست که RTT ها رو هم تنظیم کنیم که مثلا 4 تا RTT اجرا کنیم روی پورت های مختلف . برای اینکار اول از همه برید اگر از قبل RTT رو به صورت سرویس اجرا کردید خاموش کنید و سرویس رو disable کنید تا تداخل ایجاد نشه و پورت 443 رو اشغال نکنه حالا کد زیر رو که مخصوص اجرای 4 تا RTT هست اجرا کنید . متناسب با نیاز خودتون میتونید تعداد بیشتری از RTT اجرا کنید کافی هست پورت رو تغییر بدید و RTT جدید رو هم به haproxy اضافه کنید
یادتون نره که مقدار sni , password رو متناسب با نیاز خودتون تغییر بدید !
در کد های زیر در داخل سرویس من از پارامتر RuntimeMaxSec برای ری استارت خودکار RTT استفاده کردم که باید به ثانیه بهش مقدار بدید و مشخص میکنه سرویس بعد از چند ثانیه ری استارت بشه . و من 3600 رو دادم یعنی 1 ساعت ولی برای سرویس بعدی 100 ثانیه بهش اضافه کردم همون طور که توضیح دادم باید برای ری استارت یه فاصله ایجاد کنید که همه RTT ها با هم ری استارت نشن پس من هر سرویس رو تنظیم کردم که با فاصله 100 ثانیه ری استارت بشه .
RTT 1
echo '[Unit] Description=RTT 1 Service After=network.target Wants=network.target [Service] Type=simple ExecStart=/root/RTT --iran --keep-ufw --keep-os-limit --log:0 --listen:127.0.0.1 --lport:1010 --mux-width:1 --sni:github.com --password:1234 Restart=always RestartSec=3s RuntimeMaxSec=3600 LimitNOFILE=infinity StandardOutput=null StandardError=null [Install] WantedBy=multi-user.target' > /etc/systemd/system/rtt.1.service
RTT 2
echo '[Unit] Description=RTT 2 Service After=network.target Wants=network.target [Service] Type=simple ExecStart=/root/RTT --iran --keep-ufw --keep-os-limit --log:0 --listen:127.0.0.1 --lport:2020 --mux-width:1 --sni:github.com --password:1234 Restart=always RestartSec=3s RuntimeMaxSec=3700 LimitNOFILE=infinity StandardOutput=null StandardError=null [Install] WantedBy=multi-user.target' > /etc/systemd/system/rtt.2.service
RTT 3
echo '[Unit] Description=RTT 3 Service After=network.target Wants=network.target [Service] Type=simple ExecStart=/root/RTT --iran --keep-ufw --keep-os-limit --log:0 --listen:127.0.0.1 --lport:3030 --mux-width:1 --sni:github.com --password:1234 Restart=always RestartSec=3s RuntimeMaxSec=3800 LimitNOFILE=infinity StandardOutput=null StandardError=null [Install] WantedBy=multi-user.target' > /etc/systemd/system/rtt.3.service
RTT 4
echo '[Unit] Description=RTT 4 Service After=network.target Wants=network.target [Service] Type=simple ExecStart=/root/RTT --iran --keep-ufw --keep-os-limit --log:0 --listen:127.0.0.1 --lport:4040 --mux-width:1 --sni:github.com --password:1234 Restart=always RestartSec=3s RuntimeMaxSec=3900 LimitNOFILE=infinity StandardOutput=null StandardError=null [Install] WantedBy=multi-user.target' > /etc/systemd/system/rtt.4.service
حالا که سرویس رو تعریف کردیم باید همه RTT ها رو اجرا کنیم
sudo systemctl daemon-reload sudo systemctl restart rtt.1.service sudo systemctl restart rtt.2.service sudo systemctl restart rtt.3.service sudo systemctl restart rtt.4.service sudo systemctl enable rtt.1.service sudo systemctl enable rtt.2.service sudo systemctl enable rtt.3.service sudo systemctl enable rtt.4.service
خب الان باید همه چیز بدون مشکل کار کنه . اگر مشکلی بود حتما بگید . اگر راه حل دیگه ای هم سراغ دارید حتما بگید
نکته مهم
یه نکته بگم و تاکید کنم باز که من اصلا با RTT مشکل رم و سی پی یو ندارم و این مشکل روفقط با هسته های xray و sing-box داشتم و این راه حل رو روی اونا پیاده کرده بودم و جواب گرفتم . ولی چون یه تعداد گفتن که RTT رم رو اشغال میکنه راه حل رو برای RTT در کد های بالا قرار دادم ولی شما میتونید همین راه حل رو برای هسته هایی مثل ساین باکس هم پیاده سازی کنید که خیلی تاثیر داره
ممنون از اینکه وقت گزاشتید و کامل توضیح دادین با جزیات ؛ من با اجازتون اینو داکیومنت میکنم و اضافه میکنم در صفحه اصلی
البته این نکته رو هم بگم که haproxy برای وقتی خوبه که تک پورت استفاده میکنید و همچنین برنامه رو دستی اجرا میکنید
در حالت مالتی پورت خیلی بعیده کار کنه و اگرم قرار باشه کار کنه ستاپ کردنش پیچیده هست
خواهش میکنم . حتما قرار بدید که همه استفاده کنن
در حالت مالتی پورت خیلی بعیده کار کنه و اگرم قرار باشه کار کنه ستاپ کردنش پیچیده هست
درسته من خودم چون از این استفاده نمیکنم اصلا یادم نبود . البته فکر کنم haproxy این امکان رو داره که به یک range لسن کنه ولی پیاده سازیش یکم سخت میشه و نیاز داره که با lua براش یکم کد زد و به haproxy فهموند دقیقا چطوری انتقال بده به RTT
سلام وقت بخیر دوست گلم خیلی خیلی ممنونیم از لطف و بزرگواری شما که با جزئیات کامل وقت گذاشتین و توضیح دادین ایشالله همراه با مهندس عزیز خیر ببینید که رایگان وقت میزارین💚 امیدوارم همیشه سلامت باشید🌹
سلام مجدد من سرور قبلیمو به همون حالت گذاشتم که لاگش رو موقع قطعی تقدیم مهندس کنم اومدم روی دو سرور جدید و خام و بدون کاربر این روش رو تست کردم
اول دستی اجرا کردم بدون استفاده از این داکیومنت که مطمئن بشم سرورا مشکلی ندارن و ارتباط برقرار شد و ارتباط رو قطع کردم
طبق مراحل داکیومنت جلو رفتم که دستور RTT رو در سرور خارج به صورت دستی وارد کردم که نتیجه رو ببینم که با تصویر خطای زیر در سرور خارج مواجه شدم
بعد رفتم روی سرور ایران هر 4 تا RTT که به صورت سرویس در حال اجرا بود رو کاملا از سرور ایران حذف کردم و تانل فعلی رو با دستور pkill RTT متوقف کردم و مثل سرور خارج به صورت دستی دستور RTT رو اجرا کردم که خطای زیر رو در سرور ایران دریافت کردم
ناگفته نمونه طبق تذکر مهندس به صورت دستی و به صورت تک پورت تست کردم میشه بگین مشکل کجاست که اتصال برقرار نمیشه؟
طبق این لاگ ؛ به نظرم با تغییر sni مشکلتون حل میشه
سلام مهندس وقت شما بخیر
ممنونم از پیگیری و پاسخگویی شما
sni رو عوض کردم و یکی از RTT هارو دستی اجرا کردم که لاگشو ببینم اما بازم متصل نشد
لاگ سرور ایران:
لاگ سرور خارج:(همون لاگ قبلی هستش)
RTT هایی که استفاده میکنم:
RTT سرور ایران: ./RTT --iran --keep-ufw --keep-os-limit --log:0 --listen:127.0.0.1 --lport:1010 --mux-width:1 --sni:divar.ir --password:456987
RTT سرور خارج: ./RTT --kharej --iran-ip:12.21.12.21 --iran-port:443 --toip:127.0.0.1 --toport:443 --password:456987 --sni:divar.ir
اگر از haproxy استفاده نمیکنید دستوری که دارید برای سرور ایران استفاده میکنید اشتباه هست باید اینطوری باشه وقتی که بدون haproxy هست :
./RTT --iran --keep-ufw --keep-os-limit --log:0 --lport:443 --mux-width:1 --sni:divar.ir --password:456987
دقت کنید که پورت 443 باید باز باشه . اگر از ufw استفاده میکنید با دستور زیر میشه باز کرد :
ufw allow 443/tcp
برای اینکه مطمئن بشید پورت باز هست وارد ادرس زیر بشید و ایپی سرور ایران وارد کنید و پورت 443 وارد کنید باید سبز نشون بده
https://www.yougetsignal.com/tools/open-ports/
سلام آقای اکرمی وقت شما بخیر ممنونم از پاسخگویی شما دوست گلم💚 نه دارم از Haproxy استفاده میکنم و دستورات این داکیومنت رو کامل وارد کردم فقط مرحله آخر که RTT رو به صورت سرویس اجرا میکنیم، بنده این کار رو نکردم و یکی از از اون 4 آر تی تی رو به صورت دستی اجرا کردم که لاگ هاشو ببینم که لاگ هایی که ارسال کردم خدمتتون به بنده داد... مهندس گفتند sni رو تغییر بدم که این مورد هم انجام دادم اما وصل نشد..
اپدیت به زودی منتشر میشه ؛ بعد اپدیت میام مشکلات رو برسی میکنیم دقیق تر
سلام مهندس روز بخیر خیلی ممنونم از زحمات و پیگیری های شما🌹 بنده همچنان منتظرم که RTT سرور قبلی قطع بشه که لاگ هاشو تقدیمتون کنم که فکر کنم به دلیل کم شدن مصرف سی پی یو سرور ایران از دیشب که خدمتتون اطلاع دادم تا الان قطع نشده به محض اینکه قطع بشه لاگ هارو تقدیم میکنم💚🌹
مهندس جان من خودم این راه حل که دادم رو الان خواستم تست کنم و دیدم که کار نمیکنه
مشکل این هست که وقتی mode رو http باشه ظاهرا RTT به مشکل میخوره
از طرفی وقتی mode رو میزارم TCP مشکل RTT حل میشه و وصل میشه ولی دیگه کانفیگ خودم که vless+ws هست به مشکل میخوره
اگر از ws استفاده کرده باشیم باید حتما mode روی http باشه تا haproxy بتونه روت کنه
طبق خطایی که داده فکر کنم نوع درخواستی که از سمت سرور خارج میاد نمیتونه از haproxy روت بشه چون زده کاربر وصل شده ولی هیچ peer وجود نداره
این خطایی هست که RTT میده وقتی mode روی http باشه :
@radkesvat
من با netcat به پورت ایران لسن کردم تا بتونم ببینم درخواستی که از سمت کاربر و از سمت سرور خارج میاد چقدر با هم فرق دارن
فکر کنم بیخود نیست که haproxy نمیتونه هر 2 تا رو هم زمان روت کنه . چون خیلی فرق دارن
درخواستی که از سمت سرور خارج میاد :
درخواستی که از سمت کاربر میاد:
سلام لطفا نسخه جدید هم این رو تست کنید اگه هنوز مشکل پابرجا بگید
درود . با نسخه 6 تست کردم هنوز مشکل داره با haproxy من هر 2 تا mode رو تست کردم tcp http
مهندس این رو وقت کردی یه تست بزن با haproxy من با نسخه 6.1 هم تست کردم درست نشده هنوز
سلام اگه امکانش هست توضیح بدید که این کار رو چطور میشه با Xray هم انجام داد مثلا اگه 2 تا پنل x-ui نصب کنیم ، با توجه به اینکه اینا دیتابیس هاشون باهم فرق داره و مدام هم تغییر میکنه ، چطور باید اینکارو کرد که اینا باهم هماهنگ باشن؟ یا این که باید کار دیگه کرد و دیتابیس ثابته برای هر دو ؟ و یه سوالم دارم اینکه چطور باید تنظیم کنیم که کدوم xray روی کدوم هسته اجرا شه؟
شرمنده اگه سوالام گاهی مبتدی هستن ، چون خیلی از لینوکس و مسائل مربوط بهش سردرنمیارم.
انجام این روش برای پنل خیلی دردسر داره و شاید نشدنی باشه من هیچ وقت با پنل این روش رو انجام ندادم و همیشه چون دستی هسته ها رو لود میکنم به این مشکل نمیخورم به خاطر اینکه وقتی شما 2 تا xray بخواید اجرا کنید پورت ها تداخل میکنه همچنین اگر قرار باشه 2 تا پنل نصب کنید مشکل مدیریت کاربران و سینک بودنشون پیش میاد که این حتی اگر درست هم بکنید هزینه ای که از نظر منابع روی دست شما میزاره خیلی بیشتر از حالتی هست که با 1 هسته اجرا کرده باشید! بهترین راه حل این هست که خود این پنل ها یک اپدیت بدن و این ویژگی رو اضافه کنن در داخل خودشون یعنی شما به پنل بگی که xray رو 4 بار اجرا کن . اون موقع خود پنل میاد برای هر xray یه پورت در نظر میگیره و دیگه تداخل نمیکنه
مهندس این رو وقت کردی یه تست بزن با haproxy من با نسخه 6.1 هم تست کردم درست نشده هنوز
مهندس جان سلام خسته نباشی دیدم نسخه 6.2 رو منتشر کردید گفتم با اینم تست کنم ولی مشکل همچنان هست . نکته جالب این هست که اگر haproxy رو سمت خارج اجرا کنیم RTT مشکلی باهاش نداره ولی سمت سرور ایران ساپورت نمیکنه که پشت haproxy بندازیم
@radkesvat
سلام بله سر فرصت تستش میکنم متاسفانه تا قبل از این خیلی با گوست کار میکردم و از haproxy استفاده زیادی نداشتم، میرم سروقتش حتما
سلام مهندس خسته نباشی من این رو با نسخه 6.4 هم تست کردم ولی درست نشد این من هر چی میشد بررسی کردم که مطمئن بشم مشکل از haproxy هست یا نه که فکر نکنم مشکل از اون باشه به نظرم یه تغییر کوچیک داخل کد ها بتونه مشکل رو حل کنه چیزی که به ذهن خودم میرسه این هست که چون درخواست ها nat میشن این به مشکل میخوره چون الان اومدم درخواست های کاربران رو با haproxy و پورت 443 لسن کردم و فروارد کردم به RTT که روی پورت 3306 داشت به صورت گلوبال لسن میکرد از طرفی در سرور خارج به جای پورت 443 بهش پورت 3306 رو دادم یعنی کاربران با 443 به haproxy ایران وصل میشن و RTT از سمت خارج با پورت 3306 به ایران وصل میشه وقتی ارتباط تانل رو از haproxy جدا کردم مشکل حل شد . ولی وقتی ارتباط تانل هم وارد haproxy بشه دیگه کار نمیکنه گفتم شاید این بتونه کمک کنه که متوجه بشید مشکل چی هست
سلام امروز حتما میرم سروقتش ، البته انگار haproxy به جز nat کردن داره یه حرکتایی میزنه ولیلی دقیق ترشو میفهمم که چه اتفاقی داره میفته
لطفا کامند هایی که (رو haproxy ( تست کردین و جواب ندادو خیلی ساده لیست کنین اگه وقت داشتین...
تشکر
کامند خاصی نبوده همون فایل کانفیگ که در بالا قرار دادم تنها نکتش این هست که باید mode روی tcp باشه که RTT بتونه کار کنه که من برای تست کلا vless که ساخته بودم از ws به tcp تغییر دادم چون RTT فقط روی tcp کار میده ولی بازم کار نکرد بهترین راه فعلا همین هست که باید درخواست کاربران رو با haproxy دریافت کنیم و به RTT های اجرا شده در سرور ایران بدیم از طرفی سرور خارج بدون واسطه و مستقیم وصل RTT های سرور ایران بشه حالا چرا بهترین اره حل هست ؟ چون ممکن هست کانفیگ کاربر ws باشه اون موقع mode هم باید روی http باشه که اینطوری دیگه RTT کار نمیکنه چون طبق تست هایی که داشتم RTT با نوع کانکشن مشکلی نداره یعنی چ tcp و چ http داره ورودی میگیره ولی برای ارتباط با خارج حتما باید با tcp باشه ولی اگر کلا جدا کنیم این داستان رو از هم کاربر میتونه هر mode قرار بده و دیگه مهم نیست یا اینکه RTT رو طوری طراحی کنیم که روی هر 2 تا mode کار کنه تنها چیزی که هنوز من تست نکردم این بود که با netcat تست کنم فرق چیزی که از سمت سرور خارج بدون واسطه دریافت میشه با وقتی که از haproxy رد میشه چی هست . شاید این رو تست کنید متوجه بشید چ تغییری میده هرچند فکر کنم با Netcat هم به نتیجه خاصی برسیم چون طبق چیزی که من از log مشاهده میکنم کانکشن ها برقرار میشه ولی RTT نمیتونه درخواست هایی که از سمت کاربر ها میاد بندازه روی این کانکشن ها چون سمت سرور خارج میزنه که 8 تا کانکش دانلود و اپلود ایجاد کنه ولی هیچ outbound ندارن سمت سرور ایران هم log ها زده که RTT میخواد روی یک ارتباط که از قبل بسته شده read انجام بده من اول فکر کردم که شاید haproxy کانکشن ها رو close میکنه ولی طبق چیزی که حداقل من فهمیدم اینطوری نیست ضمن اینکه tcpka هم فعال کردم که کانکشن tcp رو نبنده ولی بازم فایده نداشت
این خطای close رو اگر یه بررسی کنید شاید به نتیجه برسه که چرا رخ میده
اوکی من الان میرم اینو تست میکنم ببینم چیزی میفهمم یا نه ؛ نتیجه رو همینجا میگم
دلیلشو فهمیدم ؛ چون که haproxy با ایپی 127.0.0.1 ارتباط میگیره با RTT
و خود RTT از طریق یه جدول ایپی تمایز میکنه کاربر و peer را و خوب وقتی با haproxy کانکت میشیم ؛ هم کاربر هم سرور خارج با ایپی 127.0.0.1 میرسن به RTT و به همین دیلی توی تشخیص کاربر یا سرور دچار مشکل میشه
درمورد راه حلش باید پیاده سازی رو تغییر داد و جای فکر داره ؛ اما به هر حال الان به نظرم مشکل cpu حل شده از نسخه 6 و مصرف به شکل قابل توجهی کاهش داشته اما هنوز مالتی کور نیست ...
درسته ممنون از پیگیری شما به نظرم اصلا لازم نباشه کاری بکنید . همین که فقط ارتباط ورودی که از سمت کاربر میاد رو با haproxy هندل کنیم کافی هست ارتباط با سرور خارج رو بدون واسطه برقرار میکنیم و مشکلی هم نداره فکر کنم بهتر هم باشه اینطوری
درسته ولی ارتباط خارج روی پورت های ۴۴۳ دریافت نمیشه و این از لحاظ امنیت پوئن منفی محسوب میشه ؛ به نظرم خود RTT مالتی ترد باشه خیلی بهتر از اینه هست که با haproxy درستش کنیم چون یه برنامه واسطه کمتر میشه و ۲ تا تونل داخلی در نتیجه کمتر میشه ؛ و پینگ و سرعت خیلی بهتری میشه بدست اورد حتی اگه تصور کنیم واسطه ی ما که haproxy یا حتی gost باشه کاملا ایده ال پیدا سازی شده باشه
اره این که 100 درصد حرف شما درست هست این haproxy فعلا یه راه حل موقت هست برای برنامه هایی که مالتی ترد نیستن یا در کل بهینه نیستن و نیاز باشه چند بار اجرا بشن
درود فراوان من امروز دوباره دیدم یکی در مورد haproxy سوال کرده پس سعی کردم یه تلاش دیگه بکنم تا مشکلش رو به صورت اصولی حل کنم در راه حل قبلی که دادم مشکلی که وجود داشت این بود که مجبور بودیم چندین پورت روی سرور ایران باز کنیم و دیگه از پورت 443 برای ارتباط با خارج استفاده نکنیم که این مشکلی امنیتی داشت و ممکن هست سرور فیلتر بشه ولی در این راه حل جدید مشکل رو حل کردم و الان میشه از پورت 443 هم برای ارتباط با خارج و هم برای وصل شدن کاربران استفاده کرد برای اینکه بدونید مشکل RTT دقیقا چیه میتونید پیام های قبلی بین بنده و مهندس رو بخونید ولی خلاصه بخوام بگم چون از haproxy استفاده میکنیم تمامی درخواست هایی که به RTT میره از ایپی یکسان هستن چون nat شدن و اینطوری دیگه RTT نمیتونه تشخیص بده کدوم برای کاربر هست و کدوم برای خارج اما روش حل اینطوری هست که من اومدم به haproxy گفتم اگر درخواست از سمت سرور خارج بود با ایپی 127.0.0.2 به RTT وصل بشو ولی اگر درخواست از سمت کاربر عادی بود با 127.0.0.3 اینطوری RTT میتونه درخواست های سرور خارج و درخواست از سمت کاربر رو تفکیک کنه و مشکلی دیگه با haproxy نداره تنها کاری که باید بکنید این هست که ایپی سرور خارج رو به haproxy بدید تا بتونه تفکیک کنه درخواست ها رو . که در کانفیگ پایین 1.2.3.4 رو باید با ایپی سرور خارج عوض کنید مهندس جان اگر این رو تست کنید و تایید نهایی رو بدید ممنون میشم . من با نسخه 6.7 تست کردم و مشکلی نداشت و به خوبی کار کرد اگر اوکی هست پست رو اپدیت بزنم تا کسانی که میخوان بتونن از این ویژگی استفاده کنن
global nbthread 24 maxconn 500000 tune.bufsize 49152 daemon defaults log global mode tcp option tcpka option redispatch option dontlognull option abortonclose option tcp-smart-accept option tcp-smart-connect option http-keep-alive timeout client 10m timeout server 10m timeout connect 10s timeout client-fin 10m timeout server-fin 10m timeout queue 10m retries 3 http-reuse always retry-on all-retryable-errors frontend front-443 bind 0.0.0.0:443 acl is_peer src 1.2.3.4 use_backend rtt-peers if is_peer default_backend rtt-users backend rtt-peers balance static-rr source 127.0.0.2 server s01 127.0.0.1:1010 server s02 127.0.0.1:2020 server s03 127.0.0.1:3030 server s04 127.0.0.1:4040 backend rtt-users balance static-rr source 127.0.0.3 server s01 127.0.0.1:1010 server s02 127.0.0.1:2020 server s03 127.0.0.1:3030 server s04 127.0.0.1:4040
البته اینم بگم که حتی میشه از ایپی های واقعی استفاده کرد و به جای 127 از ایپی خود درخواست کننده استفاده کنه با استفاده از PROXY protocol ولی یکم داستان پیچیده میشه و RTT هم باید از اون پشتیبانی کنه
https://www.haproxy.org/download/2.4/doc/proxy-protocol.txt
سلام آقای اکرمی وقت بخیر امروز بنده بعد از تست نسخه 6.7 مهندس کد کانفیگ جدید Haproxy که فرمودین رو تست کردم اما فراموشم شد نتیجه رو ارسال کنم خدمتتون در نسخه 6.7 کلا Fail میداد در 20 تا پینگ یکی دوتا پینگ میداد ولی نسخه 5.4 کمی بهتر بود و کمتر Fail میداد ولی بازم تعداد Fail هاش خیلی زیاد بود فیلم گرفتم خدمت شما: https://mega.nz/file/RP9EgYZK#xa1xzrVQsvzBez-ABBZESi2ASze0L1fDVsDfArnl4Nk
بنظر شما مشکل کار کجاست؟ ممنونم از زحمات شما دوست گلم