چگونه بفهمیم سرور FTP در واقع کدام نشانی را ثبت می‌کند

یک خط گزارش یک نشانی نشان می‌دهد۔ لپ‌تاپ نشانی تونل را حمل می‌کند، ممکن است اتصال از خروجی دیگری خارج شود، و بررسی مرورگری که انجام دادید چیزی درباره FTP ثابت نمی‌کند۔ این سه می‌توانند همه متفاوت باشند، و خط گزارش همیشه فقط یکی از آن‌ها را ثبت می‌کند۔ پیش از مقایسه هر چیزی، مشخص کنید درباره کدام اتصال می‌پرسید۔

این گام‌ها یک بررسی مجاز با بازه زمانی مشخص را فرض می‌کنند، نه گشتن در انتقال‌های شخص دیگری۔

1. مشخص کنید درباره کدام اتصال می‌پرسید

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

این تفکیک پیامد عملی دارد۔ یک خط ورود و یک خط انتقال از همان نشست می‌توانند دو نشانی مبدأ متفاوت را حمل کنند، بنابراین نقل هر یک از آن‌ها به‌عنوان «نشانی مشتری» حدسی درباره این است که کدام اتصال را می‌خوانید۔ پیش از تطبیق یک نشانی با هر چیزی، نوع رویداد را بررسی کنید۔

2. اتصال کنترل را دنبال کنید

مشتری را با خروجی اشکال‌زدایی فعال اجرا کنید، یا هنگام اتصال روی مشتری ضبط کنید، و همتایی را که واقعاً به آن می‌رسد یادداشت کنید۔ اگر VPN فعال باشد و مشتری از آن عبور کند، سرور نشانی خروجی VPN را می‌بیند، نه نشانی شبکه دسترسی لپ‌تاپ را۔

اگر مشتری تونل را دور بزند، سرور نشانی دسترسی را می‌بیند و نشانی خود رابط VPN هرگز روی شبکه دیده نمی‌شود۔ به همین دلیل نشانی تونل لپ‌تاپ معمولاً کم‌فایده‌ترین مقدار در تصویر است: فقط داخل تونل وجود دارد۔ برای تأیید منبعی که مشتری ارائه می‌دهد، از ss یا ضبط بسته استفاده کنید، نه خواندن آن از صفحه پیکربندی۔

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

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

اولی نقاط انتهایی محلی و همتا را فهرست می‌کند که پشته خودتان استفاده کرده است۔ دومی نشانی‌های نوشته‌شده روی شبکه را نشان می‌دهد، که به دید سرور نزدیک‌تر است اما هنوز در رابط شما متوقف می‌شود، بنابراین فقط گزارش سرور یا ضبط خود آن نشان می‌دهد سرور چه ثبت کرده است۔

3. بررسی کنید اتصال داده مطابقت دارد یا نه

در حالت غیرفعال سرور به مشتری می‌گوید کجا وصل شود، و در حالت فعال سرور به نشانی‌ای که مشتری ارائه داده برمی‌گردد۔ هر دو حالت می‌توانند اتصال داده را وقتی ترجمه یا واسطه‌ای در مسیر باشد به جایی متفاوت از اتصال کنترل بفرستند۔ حالت را از گزارش مشتری تأیید کنید، سپس بررسی کنید اتصال داده همان مسیر را به کار برده است یا نه۔

انتقالی که از نشانی متفاوت با ورود ثبت شده باشد، مشاهده واقعی است نه رکورد خراب، و معمولاً چیزی درباره مسیر می‌گوید۔

4. از اپراتور یک رکورد محدود بخواهید

به اپراتور سرور زمان نشست را همراه منطقه زمانی، حساب، عملیات و مقصد بدهید۔ بپرسید کدام اتصال میدان نشانی را ساخته و آیا واسطه‌ای قابل اعتماد معنای آن را تغییر می‌دهد۔

به جای فرض اینکه هر محصول مشتری اصلی، همتای کنترل و همتای داده را جداگانه ثبت می‌کند، طرح‌واره واقعی همان سرور را بخوانید، چون بعضی کل نشست را زیر یک خط خلاصه می‌کنند۔ پروتکل را هم روشن نگه دارید: SFTP پروتکلی مبتنی بر SSH است نه FTP روی درگاه دیگر، و FTPS به FTP مقدار TLS اضافه می‌کند، بنابراین هویت سرویس در گزارش به این بستگی دارد که کدام را مستقر کرده‌اید۔

5. پیش از نسبت دادن، تأیید کنید

یک نشانی خروجی می‌تواند به مشتریان زیادی خدمت کند، و یک حساب می‌تواند از چند مبدأ مجاز استفاده شود، بنابراین نشانی و نام کاربری یک واحد را مشخص نمی‌کنند۔ ثبت گزارش یک سیاست سرور است: VPN منبعی را که اتصال ارائه می‌دهد تغییر می‌دهد، اما نام حساب، نام پرونده یا عملیاتی را که سرویس گیرنده پردازش کرده پاک نمی‌کند۔ فقط آنچه رکورد نشان می‌دهد را نسبت دهید و بقیه را ناشناخته علامت بزنید۔ توضیح FTP در WinSCP مرجعی فشرده برای مدل دو اتصالی است، اگر لازم باشد آن را برای کسی توضیح دهید۔

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