احراز هویت پروکسی: نام کاربری و رمز یا لیست سفید IP

وقتی پروکسی می‌خرید، یک آدرس و یک پورت می‌گیرید. اگر پروکسی ترافیک هر کسی را که به آن آدرس وصل می‌شود ارسال می‌کرد، دیگران هم از آن استفاده می‌کردند. به همین دلیل هر پروکسی پولی پیش از پذیرفتن اتصال بررسی می‌کند چه کسی وصل می‌شود. دو روش رایج برای این کار وجود دارد: نام کاربری و رمز (user:pass) یا فهرستی از آدرس‌های IP مجاز (لیست سفید IP).

در این نوشته توضیح می‌دهیم هر دو روش در پشت صحنه چگونه کار می‌کنند، کدام در چه وضعیتی امن‌تر و کاربردی‌تر است و در cURL، پایتون و مرورگر با هر روش چگونه وصل می‌شوید. همچنین علت‌های خطای 407 Proxy Authentication Required را که سهم بزرگی از درخواست‌های پشتیبانی دارد، و مشکلی که IP پویا برای لیست سفید ایجاد می‌کند، بررسی می‌کنیم.

احراز هویت پروکسی چیست؟#

احراز هویت پروکسی یعنی سرور پروکسی پیش از ارسال یک اتصال بررسی کند که آن اتصال به کاربری مجاز تعلق دارد. اگر احراز هویت ناموفق باشد، پروکسی درخواست را به مقصد نمی‌فرستد.

دو روش به دو پرسش متفاوت پاسخ می‌دهند:

• نام کاربری و رمز: «آیا فرستنده این درخواست اطلاعات ورود درست را می‌داند؟»
• لیست سفید IP: «آیا این اتصال از آدرس IP مجاز می‌آید؟»

در روش نخست اطلاعات ورود درون درخواست است؛ در روش دوم منشأ اتصال نقش هویت را بازی می‌کند. همین تفاوت، قابلیت جابه‌جایی، امنیت و خطاهای رایج دو روش را شکل می‌دهد. سازوکار کلی پروکسی را در سرور پروکسی چیست و چگونه کار می‌کند؟ توضیح داده‌ایم.

اتصال با نام کاربری و رمز چگونه کار می‌کند؟#

در پروکسی‌های HTTP، احراز هویت با نام کاربری و رمز بخشی از استاندارد HTTP است. ⁦RFC 9110⁩ هدر Proxy-Authenticate را که پروکسی با آن اطلاعات ورود می‌خواهد و هدر Proxy-Authorization را که کلاینت با آن اطلاعات را می‌فرستد تعریف می‌کند. رایج‌ترین طرح Basic است که در ⁦RFC 7617⁩ تعریف شده است.

برای یک درخواست HTTPS فرایند چنین است:

1. کلاینت به پروکسی وصل می‌شود و درخواست CONNECT target.com:443 را می‌فرستد.
2. اگر درخواست اطلاعات ورود نداشته باشد، پروکسی با 407 Proxy Authentication Required و هدر Proxy-Authenticate: Basic realm="proxy" پاسخ می‌دهد.
3. کلاینت نام کاربری و رمز را به شکل user:pass به هم می‌چسباند، با Base64 کدگذاری می‌کند و درخواست را با هدر Proxy-Authorization: Basic dXNlcjpwYXNz دوباره می‌فرستد.
4. پروکسی اطلاعات ورود را بررسی می‌کند. اگر درست باشد، به مقصد وصل می‌شود و 200 Connection Established برمی‌گرداند؛ در غیر این صورت دوباره 407 می‌دهد.

بیشتر کلاینت‌ها هدر را از همان تلاش نخست اضافه می‌کنند، پس در عمل گام دوم رد می‌شود. مرورگرها ابتدا بدون هدر تلاش می‌کنند و با دریافت 407 پنجره ورود نشان می‌دهند.

نکته مهمی اینجا هست: Base64 کدگذاری است، نه رمزنگاری. هر کسی که هدر را ببیند می‌تواند در چند ثانیه آن را رمزگشایی کند و نام کاربری و رمز را بخواند. در بیشتر ساختارها اتصال میان کلاینت و پروکسی HTTP رمزنگاری‌نشده است؛ یعنی اطلاعات ورود در همین مسیر کوتاه عملاً به‌صورت متن ساده جابه‌جا می‌شود. تونل HTTPS که با سایت مقصد باز می‌شود از این هدر محافظت نمی‌کند، چون هدر پیش از ساخته شدن تونل فرستاده می‌شود.

پروکسی‌های SOCKS5 هم زیرمذاکره مشابهی برای نام کاربری و رمز دارند که در ⁦RFC 1929⁩ تعریف شده است؛ آنجا هم اطلاعات ورود بدون رمزنگاری فرستاده می‌شود.

لیست سفید IP چگونه کار می‌کند؟#

در لیست سفید IP، درخواست هیچ اطلاعات ورودی ندارد. شما یک یا چند آدرس IP را در پنل مشتری به‌عنوان مجاز ثبت می‌کنید و سرور پروکسی IP مبدأ هر اتصال ورودی را با این فهرست مقایسه می‌کند.

1. در پنل، آدرس IP عمومی دستگاهی را که از پروکسی استفاده خواهد کرد اضافه می‌کنید.
2. کلاینت بدون نام کاربری و رمز به پروکسی وصل می‌شود.
3. پروکسی به آدرس مبدأ اتصال نگاه می‌کند. اگر در فهرست باشد، درخواست ارسال می‌شود.
4. اگر آدرس در فهرست نباشد، اتصال رد می‌شود یا پاسخ 407 می‌گیرد.

منظور از «آدرس IP عمومی» آدرس محلی مانند 192.168.x.x که در تنظیمات شبکه رایانه می‌بینید نیست. آدرسی که پروکسی می‌بیند همان است که مودم یا سرور شما در اینترنت به کار می‌برد. برای یافتن آن، این فرمان را با پروکسی خاموش اجرا کنید:

curl https://api.ipify.org

بزرگ‌ترین برتری لیست سفید این است که با نرم‌افزارهایی که از اطلاعات ورود پشتیبانی نمی‌کنند کار می‌کند. برخی برنامه‌های دسکتاپ قدیمی، کلاینت‌های بازی و ابزارهای خودکارسازی در تنظیمات پروکسی فقط فیلد آدرس و پورت دارند؛ در این حالت لیست سفید تنها گزینه است.

مقایسه دو روش#

کدام امن‌تر است؟#

پاسخ یگانه‌ای وجود ندارد؛ دو روش در معرض خطرهای متفاوتی‌اند.

خطر نام کاربری و رمز، نشت است. یک فایل پیکربندی که اشتباهی به مخزن کد فرستاده شود، فرمانی که هنگام اشتراک صفحه دیده شود یا ورودی ذخیره‌شده در مرورگر یک رایانه مشترک کافی است. اطلاعات ورود نشت‌کرده از هر جای دنیا قابل استفاده است و هزینه آن به حساب شما نوشته می‌شود.

خطر لیست سفید IP، آدرس IP مشترک است. اپراتورهای موبایل و برخی ارائه‌دهندگان اینترنت خانگی با فنی به نام CGNAT مشترکان زیادی را پشت یک IP عمومی قرار می‌دهند. وقتی چنین آدرسی را به فهرست بیفزایید، کاربران ناشناسی که همان آدرس را دارند هم می‌توانند به پروکسی شما وصل شوند. همین درباره شبکه کافه‌ها، هتل‌ها و فضاهای کار اشتراکی هم صادق است.

قاعده‌های کاربردی:

• اگر از سروری با IP ثابت کار می‌کنید، لیست سفید امن‌تر است؛ رازی در کد خود حمل نمی‌کنید.
• از خط موبایل یا اتصال خانگی پشت CGNAT لیست سفید را به کار نبرید.
• اگر از نام کاربری و رمز استفاده می‌کنید، آن‌ها را در کد ننویسید؛ در متغیر محیطی یا مدیر رازها نگه دارید.
• اگر پنل شما امکان ساخت کاربران فرعی جداگانه برای کارهای مختلف دارد، از آن بهره بگیرید؛ نشت یک اطلاعات ورود فقط یک کار را متأثر می‌کند.

هر دو روش با نمونه#

آدرس‌ها و پورت‌های نمونه‌های زیر فرضی‌اند؛ مقدارهای خودتان را از پنل مشتری بردارید.

cURL#

# نام کاربری و رمز درون آدرس
curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip

# نام کاربری و رمز به‌صورت گزینه جداگانه
curl -x "http://pr.proxynet.io:8000" -U "user:pass" https://httpbin.org/ip

# لیست سفید IP: بدون اطلاعات ورود
curl -x "http://pr.proxynet.io:8000" https://httpbin.org/ip

گزینه -U که شکل بلندش --proxy-user است، چون رمز را درون آدرس نمی‌نویسد، مشکلات نویسه‌های خاص را هم کم می‌کند. گزینه‌های دیگر cURL را در استفاده از پروکسی با cURL ببینید.

Python Requests#

import os
from urllib.parse import quote

import requests

user = os.environ["PROXY_USER"]
password = quote(os.environ["PROXY_PASS"], safe="")  # نویسه‌هایی مانند @ و : و / را کدگذاری می‌کند

# نام کاربری و رمز
proxy = f"http://{user}:{password}@pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

# لیست سفید IP
proxy = "http://pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

چون اطلاعات ورود از متغیرهای محیطی خوانده می‌شود، حتی اگر فایل کد به اشتراک گذاشته شود رمز دیده نمی‌شود. ساختار چرخشی در پایتون را در چرخش پروکسی در پایتون نشان داده‌ایم. برای معادل آن در Node.js، استفاده از پروکسی در Node.js را ببینید.

مرورگر#

مرورگرها آدرس پروکسی را از تنظیمات خود یا سیستم‌عامل می‌گیرند، اما در صفحه تنظیمات نام کاربری و رمز نمی‌خواهند. وقتی پروکسی در درخواست نخست 407 برگرداند، پنجره ورود باز می‌شود و اطلاعات را آنجا وارد می‌کنید. کروم برای پروکسی‌های SOCKS5 از احراز هویت با نام کاربری و رمز پشتیبانی نمی‌کند؛ اگر می‌خواهید SOCKS5 را با کروم به کار ببرید، به لیست سفید IP نیاز دارید.

گام‌های ویندوز و کروم در تنظیم پروکسی در ویندوز و کروم و گام‌های فایرفاکس در تنظیمات پروکسی فایرفاکس آمده است. برای تنظیم در ابزار آزمون API، تنظیم پروکسی در Postman را ببینید. گزینه عبور دادن برنامه‌های دسکتاپی که تنظیمات پروکسی ندارند در Proxifier آمده است.

چرا خطای 407 Proxy Authentication Required رخ می‌دهد؟#

بخش 15.5.8 از ⁦RFC 9110⁩ کد 407 را این‌گونه تعریف می‌کند: «کلاینت برای استفاده از پروکسی باید خود را احراز هویت کند». یعنی مشکل میان شما و پروکسی است، نه در سایت مقصد. رایج‌ترین علت‌ها:

1. نام کاربری یا رمز نادرست است. یک فاصله در پایان یا تفاوت حروف بزرگ و کوچک هنگام کپی کافی است.
2. رمز نویسه خاص کدگذاری‌نشده دارد. در http://user:p@ss@pr.proxynet.io:8000 کلاینت هر چه پس از نخستین @ بیاید را نام سرور می‌داند. @ باید %40، : باید %3A و / باید %2F نوشته شود.
3. IP موجود در لیست سفید با IP مبدأ اتصال متفاوت است. مودم ریستارت شده، VPN هنوز روشن است یا در محل کار از شبکه دیگری وصل می‌شوید.
4. نرم‌افزار اطلاعات ورود را نمی‌فرستد. برخی ابزارها بخش user:pass@ آدرس پروکسی را نادیده می‌گیرند و به فیلد یا گزینه جداگانه اطلاعات ورود نیاز دارند.
5. پروتکل یا پورت نادرست. حتی با اطلاعات ورود درست، اتصال به پورت HTTP با SOCKS5 یا برعکس خطای گیج‌کننده‌ای می‌دهد.
6. حساب یا کاربر فرعی تعلیق شده است. ممکن است موجودی تمام شده، کاربر فرعی حذف شده یا سهمیه ترافیک مصرف شده باشد.

خروجی مفصل cURL به تشخیص خطا کمک می‌کند:

curl -v -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip 2>&1 | grep -iE "proxy-authorization|< HTTP"

اگر در خروجی هیچ خط Proxy-Authorization نباشد، کلاینت اطلاعات ورود را نمی‌فرستد. اگر خط باشد اما پاسخ 407 باشد، اطلاعات ورود نادرست است یا حساب مشکل دارد. معنای کدهای خطای HTTP در اسکرپینگ را در کدهای وضعیت HTTP در وب اسکرپینگ گرد آورده‌ایم.

با IP پویا چه بر سر لیست سفید می‌آید؟#

در بیشتر اتصال‌های خانگی IP عمومی ثابت نیست. وقتی مودم ریستارت می‌شود، خط قطع می‌شود یا ارائه‌دهنده در بازه‌هایی آدرس‌ها را عوض می‌کند، IP تازه‌ای می‌گیرید. آدرس قدیمی در لیست سفید بی‌اعتبار می‌شود و پروکسی اتصال را رد می‌کند.

گزینه‌های شما:

• رفتن به نام کاربری و رمز. برای اتصال‌های دارای IP پویا کم‌زحمت‌ترین راه است.
• گرفتن IP ثابت از ارائه‌دهنده. اگر کارتان همیشه از یک شبکه انجام می‌شود، راه‌حل دائمی است.
• انتقال کار به سروری با IP ثابت. سرورهای ابری معمولاً آدرس خروجی ثابت دارند و این با اسکریپت‌های اسکرپینگ و کارهای زمان‌بندی‌شده جور است.
• به‌روزرسانی خودکار فهرست اگر پنل API دارد. این به ارائه چنین APIای از سوی ارائه‌دهنده بستگی دارد.

توابع ابری و کانتینرهای با مقیاس‌پذیری خودکار ممکن است در هر اجرا آدرس خروجی متفاوتی بگیرند؛ در این محیط‌ها معمولاً نمی‌توان از لیست سفید استفاده کرد.

کاربردها#

• اسکریپت اسکرپینگ روی سروری با IP ثابت: لیست سفید، تا رمزی در کد نباشد. برای IPهای خروجی متفاوت از یک آدرس، پروکسی چرخشی به کار می‌رود.
• تیمی که از شبکه‌های گوناگون کار می‌کند: نام کاربری و رمز؛ بهتر است اگر هر عضو بتواند کاربر فرعی جداگانه داشته باشد.
• کار با حساب‌هایی که نشست لازم دارند: معمولاً نام کاربری و رمز؛ پروکسی با نشست ثابت برای حفظ همان IP در طول نشست و پروکسی ISP برای آدرس ثابت بلندمدت.
• نرم‌افزار دسکتاپ قدیمی بدون فیلد اطلاعات ورود: لیست سفید تنها گزینه است.
• کروم با SOCKS5: لیست سفید، چون کروم در SOCKS5 از احراز هویت با رمز پشتیبانی نمی‌کند.

راهنمای انتخاب#

پرسش‌های متداول#

آیا می‌توانم هر دو روش را هم‌زمان به کار ببرم؟#

به ارائه‌دهنده بستگی دارد. بسیاری از ارائه‌دهندگان روی یک حساب هم اتصال بدون رمز از IPهای لیست سفید و هم اتصال با نام کاربری و رمز از جاهای دیگر را می‌پذیرند. تنظیمات پنل این رفتار را تعیین می‌کند.

آیا نام کاربری و رمز من همراه ترافیک به سایت مقصد می‌رود؟#

نه. هدر Proxy-Authorization فقط برای پروکسی است و پروکسی آن را به مقصد نمی‌فرستد. سایت مقصد اطلاعات ورود شما را نمی‌بیند.

رمز پروکسی را چگونه امن‌تر نگه دارم؟#

رمز را در کد منبع ننویسید. از متغیر محیطی، فایل .env بیرون از کنترل نسخه یا مدیر رازهای پلتفرم خود استفاده کنید. اگر گمان می‌کنید رمز نشت کرده، فوراً آن را در پنل عوض کنید.

چند IP می‌توانم به لیست سفید اضافه کنم؟#

محدودیت بسته به ارائه‌دهنده و پلن متفاوت است. محدودیت فعلی را در پنل مشتری یا از تیم پشتیبانی می‌یابید.

چرا با وجود رمز درست خطای 407 می‌گیرم؟#

رایج‌ترین دلیل، نویسه‌های خاص کدگذاری‌نشده در رمز است. دلیل رایج بعدی این است که نرم‌افزار شما اطلاعات ورود درون آدرس را نمی‌فرستد. با فرمان curl -v بالا بررسی کنید هدر فرستاده می‌شود یا نه.

آیا لیست سفید با VPN روشن کار می‌کند؟#

با VPN روشن، با آدرس IP سرور VPN به اینترنت می‌روید. اگر IP خانه یا دفتر شما در لیست سفید باشد، پروکسی اتصال را رد می‌کند. یا VPN را خاموش کنید یا آدرس خروجی VPN را به فهرست بیفزایید؛ گزینه دوم توصیه نمی‌شود، چون ممکن است کاربران دیگری همان آدرس VPN را داشته باشند.

خلاصه#

دو راه برای احراز هویت در پروکسی وجود دارد: نام کاربری و رمزی که در هر درخواست درون هدر Proxy-Authorization فرستاده می‌شود، یا لیست سفید IP که به آدرس مبدأ اتصال نگاه می‌کند. نام کاربری و رمز در هر شبکه‌ای کار می‌کند اما اطلاعات ورود باید با دقت نگه‌داری شود؛ لیست سفید رازی در کد باقی نمی‌گذارد اما IP ثابت و غیرمشترک لازم دارد. خطای 407 تقریباً همیشه از اطلاعات ورود نادرست، نویسه خاص کدگذاری‌نشده یا IP قدیمی در لیست سفید می‌آید. برای پلن‌هایی که از هر دو روش پشتیبانی می‌کنند، نگاهی به خدمات پروکسی ما بیندازید.