وضع وكيل HTTP في Ncat مقابل مرحّل TCP ثابت
المرحّل الثابت للبايتات يترك معالجة HTTP للوكيل القائم. أما وضع الاستماع في Ncat فهو خدمة أخرى تدرك البروتوكول.
client → local TCP relay → existing forward proxy → destinationفي هذا الترتيب، للمرحّل منبع علوي واحد ثابت. يمرّر طلب العميل دون تغيير إلى الوكيل الأمامي القائم. ويقرأ ذلك الوكيل عنوان URL المطلق أو هدف CONNECT، ويطبّق السياسة، ويفتح اتصال الوجهة.
توجيه المرحّل مباشرة إلى موقع ويب يغيّر العقد. فالوكيل الأمامي يجب أن يختار الوجهات وأن يتعامل مع تأطير HTTP وسلوك الاتصال؛ واستخراج اسم مضيف من السطر الأول لا يكفي.
يوفّر Ncat من Nmap بشكل منفصل وضع استماع يدرك HTTP:
ncat --listen 127.0.0.1 3128 --proxy-type httpيستخدم مثال loopback هذا تنفيذ الوكيل في Ncat، وليس ميزة يشترك فيها كل nc. فوكيل جانب الاستماع يتعامل مع أساليب HTTP وCONNECT. وخيارات SOCKS في جانب العميل لا تنشئ خادم SOCKS في وضع الاستماع. والخدمة المشتركة الدائمة تحتاج أيضًا إلى معالجة متعمّدة للاتصالات وضبط للوصول وتسجيل.
للمراقبة، حدّد حدود التشفير. يمكن للمرحّل على اتصال وكيل HTTP عادي أن يرى طلبات الوكيل وردوده. وبعد CONNECT تكون HTTPS الخاصة بالوجهة بايتات TLS لا محتوى صفحة مقروءًا. ويكفي أن التشفير إلى الوكيل يخفي حتى التبادل الأولي على ذلك الرابط. استخدم تشخيصات العميل/الوكيل للمعاملات المفسّرة، واحمِ السجلات التي قد تحتوي بيانات اعتماد أو عناوين URL حساسة.