При обычном проксировании запросы клиента прокси-серверу на получение файла с удалённого сервера по протоколу FTP выглядят так же, как и HTTP-запросы:

GET ftp://ftp.server.info HTTP/1.1

Host: ftp.server.info

Клиентом, реализующим этот протокол FTP, в данном случае является сам прокси-сервер. Получив файл, прокси-сервер отвечает клиенту обычным HTTP-ответом и возвращает данные.

Также клиент может «потребовать» от прокси-сервера прямого соединения с удалённым хостом для обмена данными. Тогда запрос будет выглядеть так:

CONNECT ftp.server.info:21 HTTP/1.1

Host: ftp.server.info

Благодаря такому виду запросов посредник чётко понимает поставленную перед ним задачу и выполняет её в соответствии с рекомендациями системного администратора в виде директив acl и http_access в конфигурационном файле.

Общение клиента с удалённым сервером по SSL-защищённым протоколам всегда происходит по методу CONNECT:

CONNECT secure.server.info:443 HTTP/1.1

Host: secure.server.info

При прямом соединении клиента с удалённым хостом без посредников (а при прозрачном проксировании клиент «считает» именно так) он сам реализует протоколы прикладного уровня, такие как FTP и HTTP. В результате прокси-сервер не может определить поставленную перед ним задачу. При перенаправлении с помощью firewall всех соединений к портам 21 и 443 на порт прокси (3128) последний получает в первом случае строку «USER username», а во втором вообще набор несвязных символов.

Решение данной проблемы требует «хирургического» вмешательства в исходный код прокси-сервера Squid. Задача модификации сервера состоит в том, чтобы «научить» сервер становиться почти таким же посредником, как при методе CONNECT, в зависимости от номера порта запрашиваемого удалённого сервера.

Для демонстрации этой идеи напишем ещё один простейший сервер:

#!/usr/bin/perl -w

use strict;

use Socket;

# Локальный адрес мини-прокси

my $maddr = sockaddr_in(30021,inet_aton('localhost'));

# Допустим, мы уже знаем адрес удалённого FTP

my $paddr = sockaddr_in(21,inet_aton('ftp.freebsd.org'));

# Открываем сокет для прокси-сервера и начинаем прослушивать

socket(SOCK,PF_INET,SOCK_STREAM,getprotobyname('tcp')) or die $!;

setsockopt(SOCK,SOL_SOCKET,SO_REUSEADDR,1) or die $!;

bind(SOCK,$maddr) or die $!;

listen(SOCK,SOMAXCONN);

# Перехватываем сигнал PIPE. Этот сигнал появляется при попытке работы с закрытым потоком