Книга построена в стиле "вопрос ответ". Ответы бывают двух видов
| Вид материала | Книга |
- Книга Зоар, 76.85kb.
- Тест по теме Игра «вопрос-ответ», 30.32kb.
- Пояснительная записка Билеты устного зачёта по информатике состоят из двух частей:, 72.39kb.
- Ответ на вопрос 4 8 9 Ответы на вопросы, 1334.72kb.
- Задание Укажите правильный ответ на тестовые вопросы задания с использованием правовых, 204.52kb.
- Ответ: Лекция, 66.61kb.
- Чего мы хотим от школьной физической культуры? Ответы специалистов на этот вопрос часто, 279.04kb.
- Дэвид Хокинс, 5939.1kb.
- Измени свою жизнь, построй свой успех. Формула идеального успеха расширенная форма, 617.11kb.
- Как самому толковать библию ричард мэйхью, 1455.83kb.
Q: Что такое ping и для чего он нужен?
Ping – эта такая утилита для проверки работоспособности сети. Принцип ее работы в общих чертах заключается в посылке узлу эхо – запроса и ожидании от него эха – ответа. Каждый узел сети Интернет должен уметь принимать эхо – запросы и возвращать эхо – ответы, разумеется, если он подсоединен к сети и работает.
Отсутствие эхо – ответа от сервера обозначает либо сервер "висит", либо имеется неустранимое повреждение сети на участке клиент – сервер, обойти в "обход" которое невозможно.
??? Рисунок "карикатура" Чел. кричит в бассейн || горы "ау! Есть тут кто живой!" и приложив руку к уху ждет ответа. А ему в ответ "да нет тут никого!"
Это свойство делает ping удобным инструментом проверки работоспособности узла и целостности соединения. Впрочем, отрицательный результат работы ping не всегда свидетельствует о наличии какой-либо проблемы (см. "Почему ping не проходит, а сайт сервера нормально работает и открывается?").
Родственные вопросы:
Почему ping не проходит, а сайт сервера нормально работает и открывается?
Q: Где я могу достать ping?
В штатный комплект поставки Windows входит консольная версия утилиты ping, вполне удовлетворяющая запросы непритязательного пользователя. Ping в графическом исполнении можно обнаружить в составе практически любого пакета сетевых утилит (NetInfo, CyberKit и т.д.)
Комплект разработчика Windows-приложений (SDK), входящий в частности в поставку компилятора Microsoft Visual Studio, содержит исходные тексты программы ping с достаточно подробными комментариями, что легко позволяет адоптировать ее к собственным нуждам и перекроить под собственный вкус.
Q: Каково назначение ключей утилиты ping?
Несмотря на свою простоту, утилита ping из штатной поставки Windows, принимает достаточно большое количество ключей командной строки, более чем поверхностно описанных в прилагаемой документации. Неудивительно, что многие возможности ping ускользают не только от начинающих, но и умудренных жизнью пользователей!
Ключ –w используется для задания интервала ожидания эхо – ответа в миллисекундах (по умолчанию 20 секунд). Если отклик от сервера не будет получен в течение указанного времени, утилита ping сообщит "Превышен интервал ожидания для запроса", намекая на неработоспособность сервера или повреждение сети. На загруженных каналах медленных провайдеров ответ может прийти и через 30, и даже через 60 секунд, поэтому, интервал ожидания приходится увеличивать, например, так:
C:\>ping www.nastyhost.fu
Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Статистика Ping для 195.2.70.38:
Пакетов: отправлено = 4, получено = 0, потеряно = 4 (100% потерь),
Приблизительное время передачи и приема:
наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс
C:\>ping www.nastyhost.fu -w 60000
Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:
Ответ от 195.2.70.38: число байт=32 время=34100мс TTL=117
Ответ от 195.2.70.38: число байт=32 время=38310мс TTL=117
Ответ от 195.2.70.38: число байт=32 время=39001мс TTL=117
Ответ от 195.2.70.38: число байт=32 время=10220мс TTL=117
Статистика Ping для 195.2.70.38:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
наименьшее = 10220мс, наибольшее = 39001мс, среднее = 30408мс
Ключ –n задает количество отправляемых эхо – запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.
Ключ –t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш <Ctrl-C>. Внимание: <Ctrl-Break> не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера – запустил "ping www.hover-server.fu -t" и жди появления сообщения "Host Alive" или что-то в этом роде.
Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо – запросе. Допустимыми являются значения от 0 до 65.500 включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением можно выяснить зависимость скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.
Ключ –f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер не фрагментируемых пакетов. (см. "Оптимизация соединения с Интернет" и "Описание утилиты MTUSpeed").
Ключ –i задает время жизни (сокращенно TTL – Time To Live) пакета посылаемых дейтаграмм, измеряемое количеством узлов, которые может посетить пакет (по умолчанию 128). Каждый промежуточный узел уменьшает значение TTL на единицу и когда оно достигает нуля, пакет уничтожается с посылкой отправителю соответствующего уведомления. Это обстоятельство позволяет отслеживать маршрут путешествия пакетов, используя ping вместо утилиты tracert, что будет нелишним в тех ситуациях, когда tracert нет под рукой. (см. "Как определить полный путь (прохождение) при скачивании файла").
Для контроля выясним маршрут к некоторому узлу с помощью tracert, входящей в штатную поставку Windows:
Трассировка маршрута к aport.ru [194.67.18.8]
с максимальным числом прыжков 30:
C:\>tracert www.aport.ru
1 150 ms 130 ms 131 ms nas.itech.ru [195.151.210.36]
2 140 ms 141 ms 150 ms ns.itech.ru [195.151.210.33]
3 221 ms 180 ms 220 ms gw.itech.ru [195.151.210.29]
4 310 ms 401 ms 330 ms 195.151.200.90
5 300 ms 341 ms 270 ms krd-gw.mtt.ru [195.151.52.41]
А теперь вызовем ping, задав значение TTL равное одному. Первый же маршрутизатор, уменьшив его на единицу, обнаружит, что оно равно нулю и пошлет нам соответствующее уведомление. Итак…
C:\>ping www.aport.ru -i 1
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.36: Превышен срок жизни (TTL) при передаче пакета.
И в самом деле, получен ответ от узла 195.151.210.36 – первого маршрутизатора в цепочке, как это видно по протоколу работы tracert.
Теперь увеличим значение TTL до двух и повторим процедуру:
C:\>ping www.aport.ru -i 2
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.33: Превышен срок жизни (TTL) при передаче пакета.
Действительно, теперь найдет второй маршрутизатор в цепочке! Увеличиваем значение TTL еще на единицу…
C:\>ping www.aport.ru -i 3
Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:
Ответ от 195.151.210.29: Превышен срок жизни (TTL) при передаче пакета.
В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом следующего содержания {>>>> сноска Работает только под Windows 2000 или выше} FOR /L (%%I) IN (1,1,30) DO ping %1 -i %%I, вызываемого с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.
Ключ –v задает значения поля типа службы (TOS - Type Of Service). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета – нельзя одновременно требовать молниеносной скорости пересылки пакета в купе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!
Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 3). Как легко видеть, каждому значению соответствует свой бит:
-
Код сервиса
Пояснение
2
минимальные издержки на пересылку
4
максимальная надежность доставки
8
максимальная пропускная способность
16
минимальная задержка
Таблица 3. Допустимые типы сервиса в поле TOS
Не все маршрутизаторы анализируют поле TOS, - многие из них его напрочь игнорируют, что и подтверждает следующий эксперимент.
C:\>ping www.itech.ru -v 0x2
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru -v 0x4 -n 1
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru -v 0x8 -n 1
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
C:\>ping www.itech.ru -v 16
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254
Независимо от типа сервиса время отклика всегда составляло ровно 130 мс, и быстроты пересылки при TOS равном 16 не наблюдалось. А вот пример сети, поддерживающей TOS.
C:\>ping www.krintel.ru -v 2
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Ответ от 195.161.42.218: число байт=32 время=2143мс TTL=127
C:\>ping www.krintel.ru -w 10000 -v 4
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Ответ от 195.161.42.218: число байт=32 время=1763мс TTL=127
C:\>ping www.krintel.ru -v 8
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Превышен интервал ожидания для запроса.
Ответ от 195.161.42.218: число байт=32 время=1332мс TTL=127
C:\>ping www.krintel.ru -v 16
Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:
Ответ от 195.161.42.218: число байт=32 время=1092мс TTL=127
Наибольшая задержка наблюдалась при TOS равном 2 (минимальные издержки на пересылку), а наименьшая – при TOS равным 16 (минимальная задержка), и чуть менее быстрой оказались посылки с TOS равным 8.
Какую пользу из этого можно извлечь? А вот какую – прикладные программы могут манипулировать полем TOS по своему усмотрению, выбирая значение, соответствующее специфике своей работы. Например, telnet-клиенты, ICQ и чаты очень чувствительны к задержкам, ftp клиентам задержки не страшны – была бы хорошей пропускная способность, и т.д. Разумеется, если промежуточные узлы игнорируют содержимое поля TOS, никакого выигрыша не получается и высокоприоритетные пакеты (например, от ICQ) обрабатываются с той же скоростью, что и пакеты, скажем, от почтового сервера, не критичные к скорости доставки. Использование ping с ключом –v позволяет выяснить поддерживается ли TOS на данном маршруте и если имеется несколько альтернативных маршрутов – выбрать из них наиболее подходящий {>>>>> сноска К слову сказать, далеко не все приложения устанавливают поле TOS в соответствующее значение, оставляя его по умолчанию}
Ключ –r заставляет промежуточные узлы записывать в заголовок отправляемых эхо – запросов свои IP-адреса (см. " Можно ли обойти защиту от трассировки?"). Не все маршртузаторы поддерживают такую возможность, но очень многие. Ping, вызванная с ключом –r, позволяет отслеживать маршрут пересылки пакетов и могла бы полностью заменить собой утилиту tracert (см. "Как определить полный путь (прохождение) при скачивании файла") если бы не ограничения, налагаемые размером IP-заголовка на максимальное количество запоминаемых адресов, – их умещается всего девять, и более длинные пути отслеживать этим способом невозможно.
Ключ –s похож на ключ –r, но заставляет промежуточные узлы вносить в заголовок не свои адреса, а временную метку (или "штамп времени" в плохом русском переходе). По общепринятым соглашениям временная метка представляет собой четырехбайтовое поле, содержащее число миллисекунд, истекших с начала полуночи всеобщего скоординированного времени, однако, на практике это соглашение мало кто соблюдает и многие маршрутизаторы заполняют это поле всякой отсебятиной, интерпретируемой только одним им известным способом.
На количество запоминаемых временных меток наложены те же самые ограничения, что и на количество запоминаемых IP-адресов, за одним небольшим исключением – временная метка, вставленная неизвестно каким маршрутизатором, бесполезна (разве что маршрут путешествия пакетов заведомо не меняется с течением времени и может быть предварительно выявлен трассировкой). По умолчанию утилита ping автоматически запоминает IP-адреса узлов при записи временных меток – таких пар в заголовок пакета может вместиться только четыре.
Временная метка выгодно отличается тем, что позволяет вычислять точную скорость пересылки пакета, поскольку содержит в себе не общий интервал задержки (от пересылки в оба конца), а время пересылки на заданный узел. По непонятным причинам штатная (да и большинство остальных) реализация утилиты ping не позволяет задавать запись временной метки для произвольного узла в цепочке (хотя, в принципе это возможно), чем полностью обесценивает ключ –s, ну, право же, редкий сервер отделен от клиента менее чем четырьмя промежуточными узлами!
Пример вызова ping с ключом –s приведен ниже. Обратите внимание на временную метку – похоже она представляет собой ни что иное, как случайное число.
C:\>ping www.itech.ru -s 2
Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:
Ответ от 195.151.210.34: число байт=32 время=151мс TTL=254
Штамп времени: 195.151.210.36 : 3658968578 ->
195.151.210.34 : 2275040770
Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254
Штамп времени: 195.151.210.36 : 3357240834 ->
195.151.210.34 : 1956535810
Ответ от 195.151.210.34: число байт=32 время=141мс TTL=254
Штамп времени: 195.151.210.36 : 3122621954 ->
195.151.210.34 : 1738694146
Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254
Штамп времени: 195.151.210.36 : 2888003074 ->
195.151.210.34 : 1504075266
Статистика Ping для 195.151.210.34:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
наименьшее = 140мс, наибольшее = 151мс, среднее = 143мс
Ключ –j задает список узлов для свободной маршрутизации от клиента и аналогичен одноименному ключу утилиты tracert (см. " Каково назначение ключей tracert?").
Ключ –k похож на ключ –j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление, дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, – современные сети самостоятельно решают проблемы маршрутиазции пакетов и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.
Ключ –-a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен – такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".
Родственные вопросы:
Провайдер и удаленный доступ Оптимизация соединения с Интернет
Провайдер и удаленный доступ Описание утилиты MTUSpeed
Как определить полный путь (прохождение) при скачивании файла
Можно ли обойти защиту от трассировки?
Каково назначение ключей tracert?
Q:Почему ping не проходит, а сайт сервера нормально работает и открывается?
Бывает, – ping к некоторому серверу упорно не проходит, какую бы ни выбрал задержку, но все сервисы (будь то почта или web) работают нормально. Почему? Все объясняется очень просто – администратор сервера защитил его межсетевым экраном, блокирующим либо эхо - запросы, либо эхо – отклики, либо и те, и другие вместесразу. А может запрет эхо – откликов наложен на сам узел.
Все эти меры предосторожности объясняются тем, что эхо – посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться) и злоумышленники могут перегрузить сервер, направив на него штурм эхо – запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже направить шторм эхо – запросов от имени жертвы, выходящей в Интернет по модему, – на нее обрушится сокрушительная лавина эхо – ответов от быстродействующего сервера (хорошо если одного), плотно забивающая канал…
Вот поэтому-то, для заблаговременного предотвращения возможности атаки, эхо – посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают как ни в чем не бывало работать!
A:Что такое DNS?
Для успешного функционирования любой коммуникационной сети каждый из ее узлов должен обладать некой уникальной характеристикой, отличающей его ото всех остальных. В телефонии для этой цели используется абонентский номер, а в Интернете – IP-адрес. Такая аналогия вполне уместна: IP-адрес состоит из адреса сети (что-то вроде кода города или страны), адреса подсети (по аналогии: номера АТС) и адреса узла (номера абонентского комплекта, находящегося на этой АТС). На заре развития Интернет все узлы и соответствующие им имена перечислялись в специальном host-файле, который, подобно телефонному справочнику, периодически обновлялся и рассылался абонентам сети.
Но даром что ли компьютер призван облегчать человечеству жизнь? Вот и предложили все операции с доменными именами автоматизировать и возложить эту заботу на него. Перед разработчиками стояла задача: создать высокопроизводительную базу данных, способную функционировать в сети с огромным количеством узлов и рассчитанную на одновременную обработку множества запросов. Владельцами локальных сетей высказывались пожелания в пользу децентрализованной системы, статус каждого субъекта которой соответствовал бы его роли в сети Интернет. Проще говоря, администраторы требовали права самостоятельно выдавать доменные имена своим подопечным, не дожидаясь пока NIC (Net-world Information Center) обработает поданные ему заявки и внесет исправления в host-файл (а ведь когда-то все так и происходило!)
Таким требованиям отвечала идея иерархического пространства имен – дерева, листья которого хранятся на множестве компьютеров, разбросанных по всему свету, а их администрирование возложено на организаторов подсетей, подключенных к Интернету. Каждому из них предписано установить собственный сервер, содержащий информацию о локальных доменах и способный обслуживать пользователей как внутри подсети, так и за ее пределами.
Существенными недостатками распределенной базы данных является: низкая скорость обработки запросов, плохая согласованность информации и недостаточно высокая надежность системы. Но попытка компенсировать падение производительности путем локального кэширования приводит к еще большей несогласованности и недостоверности полученных данных. Отказавшись от поисков "золотой середины", разработчики постановили: обеспечение доступа к базе – более приоритетная задача, чем целостность и согласованность информации, а любые изменения в системе имен должны вноситься так, чтобы не препятствовать доступу к ресурсу по прежним адресам.
Подобную базу данных в принципе можно реализовать посредством любого существующего протокола, например, скачивать ее по ftp, пересылать по электронной почте и т.д. Но по соображениям совместимости эту службу в 1984 году выделили в самостоятельный протокол, технически обозначенный как DNS (Domain Name System).
Таким образом, DNS - сервис необходим для обеспечения доступа к базе данных, ассоциирующей доменные имена с IP-адресами узлов, которые необходимо "знать" межсетевому IP-протоколу для установки соединения.
>>>>> Врезка
Доменное имя состоит из одного или нескольких поддоменов, разделенных для удобства построения иерархии символом точки, причем порядок задается справа налево. Использование национальных кодировок в именах доменов до сих пор недопустимо, что вызывает неудобства у неанглоязычной части населения планеты (причем препятствия в решении этой проблемы не технические, а скорее организационные – попробуй-ка заставить всех администраторов перейти на новую версию DNS-протокола, поддерживающего UNICODE-кодировку).
Наверху иерархии стоят домены первого уровня, находящиеся во владениях Корпорации Распределения Доменных Имен (ICANN), определяющей порядок и правила регистрации поддоменов. До 14 сентября 1995 года эта услуга осуществлялась на некоммерческой основе и выполнялась бесплатно. На выбор предоставлялось 6 доменов высшего уровня (не считая двухбуквенных кодов стран): "gov" – для правительственных учреждений, "mil" – для военных организаций, "edu" – учебных заведений, "com" – коммерческих фирм, "org" – бесприбыльных организаций и "net" – поставщикам сетевых услуг.
Впрочем, тематика ресурса может и не соответствовать занимаемому им домену, – никто не запрещает коммерческой организации регистрироваться в домене "org", а уж тем более предоставлять домены третьего уровня, скажем, поставщикам сетевых услуг. Кроме того, такая классификация оказалась несовместима с национальными доменами и породила перлы наподобие "Name.com.ru".
В настоящее время наибольшая концентрация ресурсов наблюдается в домене "com", приглянувшемся не только американским, но и национальным организациям, порой добавляющих свой поддомен слева, скажем так: Name.Ru.com. Это приводит к нехватке уникальных комбинаций, порождающей в свою очередь такое неприятное явление как спекуляция доменами второго (редко – третьего) уровня.
Проблему пытаются решить введением новых специализированных и национальных ("сс" – Кокосовые Острова, "tv" – Тувалу, "md" – Молдавия и т.д.) доменов. Но с ростом ассортимента верхних доменов усложняется поиск необходимого ресурса, – большинство организаций попадает под множество категорий одновременно, и, попробуй-ка, угадай - на каком домене они могут быть расположены!
<<<<<<
Когда пользователь пытается установить соединение с каким-нибудь узлом, скажем, ссылка скрыта, браузер (или другое программное обеспечение) обращается к DNS-серверу (IP-адрес которого прописан в настройках TCP/IP соединения клиента) с просьбой определить IP-адрес этого домена. В зависимости от настроек сервера возвращает либо требуемую информацию, либо ссылку на соседний DNS-сервер, который, по его мнению, более компетентен в этом вопросе.
>>>> Врезка 2
По соображениям производительности весь обмен ведется по протоколу UDP, которой, в отличие от TCP, работает без установки соединения, в результате чего не может надежно идентифицировать отправителя пакета. Эта, казалась бы, несущественная техническая тонкость выливается в концептуальную уязвимость, – любой злоумышленник может навязать своей жертве ложный маршрут, полностью перехватывая исходящий трафик.
Причем на сегодняшний день надежной защиты от таких посягательств не существует и вряд ли она появится в обозримом будущем! Спасает лишь тотальная безграмотность подавляющего большинства злоумышленников, умственные возможности которых реализовать описанную выше атаку не позволяют (известен лишь один случай подмены главной страницы сайта компании "ROSNET", путем нападения на DNS сервер). Подробнее об этой проблеме можно прочитать в книгах "Атака на Интернет" и "Техника сетевых атак", написанных Ильей Медведовским и Крисом Касперски соответственно.
<<<<
Возвращенный ответ попадает в кэш и необходимость постоянного обращения к DNS-серверу более высокого уровня отпадает. Поскольку существует резко выраженное преимущество посещаемости одних узлов перед другими, большинство запросов обрабатывается ближайшим DNS-сервером самостоятельно, а то и вовсе содержится в локальном кэше DNS-клиента! В результате этого накладные расходы на перевод доменных имен в IP-адреса пренебрежительно малы, и до тех пор, пока в сети не происходит никаких изменений - все работает нормально. В противном случае пользователи будут вынуждены караулить у моря погоду, ожидая обновления содержимого кэша используемого DNS-сервера. Так, например, провайдер "Зенон", реорганизуя свою подсеть, оставил меня без доступа к почтовому ящику на целых две недели с хвостиком, – вот такой маленький эпизод из жизни!
Было бы нечестно, говоря о достоинствах DNS, не отметить того обстоятельства, что на сегодняшний день лишь незначительная часть ресурсов сети представлена доменными именами второго уровня. Типичная ссылка состоит из леса поддоменов, суммарная длина которых заметно превышает 8-байт IP-адреса, а осмысленность и легкозапоминаемость – скорее исключение, чем правило (слабо с лету запомнить .nasa.gov?).
В принципе проблему наименования узлов можно решить и на клиентской стороне – умеют же многофункциональные телефонные агрегаты вызывать абонента нажатием одной клавиши, а современные почтовые приложения автоматически подставлять адрес получателя по его имени?
Если проблемы, связанные с DNS (позволю себе напомнить их еще раз –
а) небезопасность;
б) нехватка и путаница доменных имен;
в) болезненная чувствительность к вносимым изменениям)
- не разрешается, вполне возможно, что в скором будущем использование "голых" IP-адресов обретет вторую популярность, – ведь запоминать их ничуть не труднее, чем телефонные номера, а цифры по-своему притягательны и красивы.
Родственные вопросы:
Что такое дерево (стек) протоколов?
Можно ли увидеть карту всего Internet, связи, каналы, структура?
Безопасность Чем рискует посетитель виртуального магазина?
Q: Что такое Proxy-сервер и как с ним работать?
Абстрагируясь от всех технических деталей и подробностей, представим себе Proxy-сервер эдаким посредником между другим сервером и клиентом. Грубо говоря, вместо того чтобы идти в магазин самостоятельно, клиент поручает покупку товара торговому агенту. Зачем это может быть нужно? О, на то существует масса причин! Во-первых, если несколько сотрудников фирмы позарез захотели отобедать гамбургером, то непрактично идти всем стадом в ближайший Макдональс – лучше отправить одного человека, а то и вовсе ввести специальную должность пищевого агента, глядишь, – и сотрудники отрываться от работы меньше будут. Во-вторых, смышленый агент не будет дожидаться заявок пользователей, а, изучив их вкусы и пристрастия, закупит все продукты заблаговременно – захочет кто-нибудь Хот-Дог и вот он, пожалуйте, откушать! В-третьих, посредник позволяет покупателю сохранить анонимность – его личность будет знать только сам агент, остается лишь подобрать такого агента, который не выдаст!
??? Рисунок "карикатура" – обыграть предыдущий абзац
Все типы Proxy-серверов можно разделить на три категории: шлюзы, кэшируюшие Proxy-сервера и анонимные Proxy-сервера.
Шлюзы чаще всего используются в локальных сетях – было бы слишком накладно каждому клиенту предоставлять свой собственный "персональный" выход в Интернет. Вот и устанавливают Proxy-сервер, разделяющий один канал между множеством пользователей. Однако, такую тактику используют и некоторые алчные провайдеры (например, krintel – треска ему хвостом вперед!), выкупающие у более крупного провайдера всего один выход в Интернет и всего один постоянный IP-адрес (а то и вовсе обходящиеся без оного), "сажая" на него всех пользователей.
"Извне" остальные абоненты сети видят лишь один узел – Proxy-сервер этого провайдера. Клиент дает Proxy-серверу запрос на установку соединения с таким-то сервером и Proxy выполняет ее от своего имени, возвращая ответ сервера клиенту.
Чем плоха такая схема? В первую очередь невозможностью ни одному внешнему узлу сети самостоятельно установить с клиентом соединение – Proxy просто не будет знать кому именно предназначается этот запрос, поэтому установка соединения из-под Proxy работает только в одном направлении – от клиента к серверу. Такой расклад не дает работать множеству программ, наподобие ICQ, пейджеров, чатов и т.д., так они требуют двухсторонней установки соединения и, если программист явно не предусмотрел возможности работы под Proxy-сервером, придется либо отказываться от использования таких программ, либо менять провайдера. Другое, не столь существенное, но все же досадное ограничение, – невозможность трассировки маршрута в обоих направлениях (см. "Почему трассировка умирает на полпути к серверу назначения") и "пинговки" извне. Но у сетевых жителей, обитающих за Proxy-сервером, есть и свои преимущества, главное из которых – повышенная защищенность, ведь атаковать клиента можно только изнутри (т.е. в рамках сети одного провайдера), а все атаки "извне" принимает на себя Proxy-сервер!
Шлюзы в свою очередь делятся на два подтипа – SOCKS-Proxy и шлюзы уровня приложений.
SOCKS-Proxy работают на сетевом уровне и невидимы для прикладных программ, которые даже не подозревают о существовании Proxy-сервера. От пользователя требуется всего лишь установить Proxy-клиента, выданного ему провайдером, и никаких специальных настроек используемого программного обеспечения! (Равно как и перехода на использование программ специально спроектированных для работы с Proxy-сервером) Единственное условие – порты, через которые эти приложения работают, должны быть открыты на Proxy-сервере. А так бывает не всегда – многие администраторы зачастую закрывают порты, используемые некоторыми потенциально опасными, с их, администраторской, точки зрения, приложениями и упрямо не соглашаются их открыть!
Шлюзы уровня приложений, как и следует из их названия, работают на прикладном уровне и взаимодействуют со строго определенными приложениями через заранее оговоренные порты. Причем, программное обеспечение должно быть спроектировано соответствующим образом и явно поддерживать Proxy-сервер. Узнать поддерживает ли такое-то приложение Proxy-сервер или нет, можно из прилагаемой к нему документации, там же рассказано как эту поддержку включить. Шлюзы уровня приложений чрезвычайно стесняют и ограничивают клиента – ему предоставляется доступ к ограниченному количеству служб (например, только www и ftp) и приходится пользоваться только определенными приложениями – теми, что поддерживают работу через Proxy! Провайдер, предоставляющий доступ с Сети только через шлюз уровня приложений, – самое худшее, что может присниться интернетчику в кошмарном сне. К счастью, сегодня такие практически полностью перевелись – конкуренты задушили. И поделом!
Кэширующие Proxy в основном представляют собой шлюзы уровня приложений, но, в отличие от них, используются факультативно, т.е. по желанию клиента. Хочешь – входи в сеть напрямую, хочешь – используй кэш-сервер. Использование таких Proxy позволяет значительно увеличить скорость обмена данными, особенно при соединении с далекими, загруженными серверами. Будучи подключенным к быстрому каналу, гораздо более быстрому, чем модемная линия, кэш-сервер сглаживает провалы и кратковременные "засыпания" удаленного сервера. Полученные данные Proxy сохраняет на своем диске – кэше и, если запрошенный клиентом ресурс уже был загружен какое-то время назад, он молниеносно "отдается" ему без обращений к удаленному серверу! Конечно, это не слишком хорошо подходит для интенсивно обновляющихся ресурсов, но большинство "умных" Proxy периодически проверяют ресурс на наличие изменений (иногда при каждом запросе оного) и обновляют свой кэш.
Анонимные Proxy – анонимными серверами называются те, которые выполняют запрос клиента от своего имени, не разглашая его IP-адреса. Вряд ли стоит объяснять зачем нужна анонимность – она полезна не только для хулиганских выходок (типа загадил такой-то форум и рад, что никто не найдет и не поймает), но и мирных житейских ситуациях.
Родственные вопросы:
Почему трассировка умирает на полпути к серверу назначения
Как заставить работать такое-то приложение через Proxy-сервер?
Q:Как заставить работать такое-то приложение через Proxy-сервер?
Работа через SOCKS Proxy-сервер (см. "Что такое Proxy-сервер и как с ним работать?") не требует никаких особенных настроек за исключением установки SOCKS Proxy-клиента, – специальной программы, выдаваемой провайдером (администратором) вместе с подробными инструкциями по установке.
Однако Proxy не поддерживает входящие соединения (попросту говоря, не разрешает серверу соединится с клиентом), и все приложения, нуждающиеся во входящих подключениях, отказываются функционировать. К их числу относятся: клиенты ftp (см. "Не могу скачать файл с ftp через Proxy-сервер (Firewall)! Почему это и как быть?"), Интернет-пейджер ICQ и другие программы (см. "Как заставить работать ICQ через Proxy или firewall?")
Со шлюзами уровня приложений все гораздо сложнее: через http- или ftp-Proxy могут работать лишь приложения, явно предусматривающие такую возможность. Ряд программ, например, почтовые клиенты, вообще не могут работать через шлюзы уровня приложений и пользователи вынуждены отказываться от их использования, выбирая альтернативный сервис, доступный через web, а, если по каким-то причинам это невозможно, – сушите весла лаптями в сторону.
Ниже будет показано как настроить три популярных приложения ReGet, Internet Explorer и Teleport Pro для работы через http Proxy сервер. О настройке других приложений можно узнать из прилагаемой к ним документации
ReGet
В меню "Настройки" выберите пункт "Свойства закачки по умолчанию" (или нажмите комбинацию клавиш <Ctrl+Alt+O>) и в открывшемся диалоговом окне перейдите к закладке "Прокси".
Для работы через HTTP Proxy-сервер взведите галочку "Использовать для HTTP" и строкой ниже укажите адрес сервера и номер порта, отделенный от адреса двоеточием, например, так: proxy.itech.ru:3128 (номер порта и адрес сервера можно узнать у администратора сети или провайдера). Если Proxy требует аутентификации, в строке "Имя" введите свой логин, а в строке "Пароль" свой пароль. В графе "Откат на" укажите количество байт которые будет отрезаться от хвоста скаченного файла при каждом разрыве соединения (подробнее см. "Я скачал файл с сервера, а он отказывается распаковываться (запускаться). Кто виноват и что делать?"). Галочка "Хитрый откат" будучи взведенной задействует продвинутый алгоритм отрезания хвоста, пытающийся определить точное положение "мусора" в хвосте, дабы не отрезать лишнего. Анализируя поток данных, ReGet ищет строки характерные для сообщений об ошибке (по умолчанию – "HTTP/1.,"). Если ваш Proxy-сервер информирует об ошибке каким-то иным образом (что, впрочем, достаточно маловероятно) добейтесь появления в окне браузера сообщения о такой ошибке, а затем в меню "Вид" выберите "В виде HTML" и скопируйте самую верхнюю строку в поле "Список первых символов сообщения об ошибке" диалогового окна настроек ReGet. Вообще-то, от использования "хитрого отката" лучше отказаться – он, экономя всего лишь несколько секунд на каждый разрыв соединения, создает угрозу необратимо испортить скачиваемый файл так, что его будет проще скачать сначала, чем восстановить. Так стоит ли рисковать?
Для работы через ftp Proxy-сервер взведите галочку "Использовать для FTP" и строкой ниже укажите адрес сервера и номер порта, отделенный от адреса двоеточием, например, так: proxy.itech.ru:3128 (номер порта и адрес сервера можно узнать у администратора сети или провайдера). Если Proxy требует аутентификации, в строке "Имя" введите свой логин, а в строке "Пароль" свой пароль. В большинстве случаев провайдеры предоставляют один Proxy для ftp- и http-протоколов, для работы с которым радио кнопка графы "Тип FTP прокси" должна находится в положении "HTTP". Если же соединение осуществляется через WinGate или Microsoft Proxy, требующих представлять адрес ftp-сервера и имя пользователя в виде адреса электронной почты, перекиньте эту радио кнопку в положение "user@site".
Ограничения: ReGet поддерживает только базовый алгоритм аутентификации и не умеет передавать на Proxy зашифрованный пароль. Некоторые администраторы запрещают базовую аутентификацию по соображениям безопасности (пароль, переданный открытым тестом, легко перехватить), что приводит к неработоспособности ReGet. Выход состоит в установке SOCKS Proxy-клиента, самостоятельно перехватывающего запросы на установку соединения и переправляющие их на Proxy. Обратите внимание – при работе через Proxy-клиента галочки "Использовать для HTTP" и "Использовать для FTP" в настройках ReGet следует сбросить.
Рисунок 12 рис 0х022 Настройка ReGet для работы через Proxy-сервер
Internet Explorer
В меню "Сервис" выберите пункт "Свойства обозревателя" и в открывшемся диалоговом окне перейдите к закладке "Подключение". Нажмите кнопку "Настройка сети", находящуюся в графе "Настройка локальной сети", затем взведите галочку "Использовать прокси-сервер" и в строке "Адрес" введите IP-адрес или доменное имя Proxy-сервера, а в строке "Порт" – номер порта (как правило, 80). Если в локальной сети есть один или несколько web-серверов, для обращения к ними в обход Proxy-севера взведите галочку "Не использовать прокси – сервер для локальных адресов".
Кнопка "Дополнительно" открывает новое диалоговое окно для более тонкой настройки, позволяя по раздельности задавать адреса и порты Proxy-серверов для http-, ftp-, Gopher- и Socks-протоколов. Конкретные значения можно узнать у администратора сети или провайдера. Чаще всего используется один Proxy для http- и ftp-протоколов, "повешенный" на 80, 8080 или 8081 порт, хотя номер порта в принципе может быть любым. Socks-сервера по обыкновению "висят" на порту 1080, а протокол Gopher в настоящее время считается достойным пережитком старины и более не используется. Галочка "Один прокси сервер для всех протоколов" будучи взведенной приводит к использованию адреса и порта http Proxy-сервера для всех остальных протоколов.
Графа "исключения" позволяет задавать шаблоны IP-адресов (доменных имен) обращения к которым будет происходить напрямую, "в обход" Proxy-сервера. В шаблонах допустимы символы-джокеры, а сами шаблоны отделяются друг от друга точкой с запятой. Например, чтобы не "проксить" web-узлы, находящиеся в доменах ru и ua, достаточно ввести следующее: "www.*.ru;www.*.uk". Подобная настройка полезна в тех случаях, когда провайдер предоставляет факультативный Proxy (т.е. позволяет выходить в Интернет как через Proxy, так и минуя оный). Разумно использовать Proxy только для далеких, забугорных, тормозных узлов, а к быстрым серверам обращаться напрямую, не прибегая к Proxy, т.к. это не увеличит и без того высокой скорости загрузки сайтов, а скорее замедлит ее за счет дополнительных "перекладных" на маршруте путешествия пакетов.
Аутентификация: если Proxy-сервер требует аутентификации, т.е. ввода имени пользователя и пароля, то Internet Explorer автоматически подставляет имя и пароль под которым пользователь вошел в систему. Для этого необходимо установить "Клиента сетей Microsoft" ("Панель управления" "Сеть" "Добавить" "Клиент" "Клиент сетей Microsoft"), а в некоторых случаях установить "Общий доступ к файлам и папкам" – Windows 98 при этом добавит новые компоненты, поддерживающие большое количество алгоритмов аутентификации – в противном случае система будет передавать пароль открытым текстом, что не всегда приемлемо. Задать произвольный пароль для входа на Proxy-сервер браузер Internet Explorer не позволяет.
Рисунок 13 Рис. 0х023 Настройка Internet Explorer для работы через Proxy-сервер
Teleport Pro
В меню "File" ("Файл") выберите пункт "Proxy server" ("Proxy-сервер") и в появившемся диалоговом окне взведите галочку "Connect to the Internet through this proxy server" ("Подключаться к Интернет через этот Proxy-сервер"), а строкой ниже введите его IP-адрес (доменное имя) и номер порта. Если Proxy-сервер требует аутентификации в строке "Proxy Account" введите свой логин, а в окне "Proxy Password" – пароль. Нажмите "ОК" и на этом процедуру настройки можно считать завершенной.
Родственные вопросы:
Что такое Proxy-сервер и как с ним работать?
Не могу скачать файл с ftp через Proxy-сервер (Firewall)! Почему это и как быть?
Как заставить работать ICQ через Proxy или firewall?
Получение файлов Я скачал файл с сервера, а он отказывается распаковываться (запускаться). Кто виноват и что делать?
Q:Как заставить работать ICQ через Proxy или firewall?
Нажмите кнопку "ICQ" и в появившемся меню выберите пункт "Preferences" (предпочтения), затем в открывшемся диалоговом окне перейдите к закладке "Connection" (подключение). В секции "Internet connection Type" (тип соединения с Интернет) нажмите кнопку "Firewall Settings" ("Настройки Firewall и Proxy-сервера" – о Proxy ничего не говорится, видимо, разработчики полагали, что пользователи, не обделенные даром ясновидения, об этом догадаются самостоятельно). Если же она заблокирована – проделайте следующие шаманские манипуляции: переместите радио кнопку в положение "I'm using a permanent internet connection (LAN)" (Я использую постоянное соединение с Интернет типа локальной сети) даже в том случае, если выходите в сеть через модем. Это необходимо для того, чтобы разблокировать два следующих пункта, указывающие выходите ли вы в сеть через Proxy (Firewall) или соединены напрямую, минуя оные. Переместите радио кнопку в положение "I am behind a firewall or proxy" ("Моя сидеть за Firewall или Proxy" – явно чувствуется иностранный акцент разработчиков) – это разблокирует кнопку "Firewall Setting". Теперь можно вернуть тип Интернет - соединения на подключение через модем (если вы действительно выходите через модем), переместив радио кнопку в положение "I'm using a modem (or any other dial-up device)" ("Я использую модем или другое диалапное устройство") – пункты выбора "Firewall или не Firewall" тут же поблекнут, но кнопка "Firewall Setting" останется гореть ярким пламенем – нажмите ее! (Руки разработчиков растут из того места, которым они думают).
Появится диалог " ICQ Firewall Setting Wizard" – мастера настройки подключения через Firewall или Proxy-сервер. Текст, выведенный мастером, в переводе гласит следующее: "Пожалуйста, проконсультируйтесь у вашего сетевого администратора касательно настроек Firewall-а/Proxy-сервера". А именно – установлен ли Proxy-сервер и если да то какой: SOCKS 4, SOCKS 5 или какой-то другой? Каково доменное имя (IP-адрес) Proxy-сервера, номер порта, требуется ли авторизация и если да, то попросите сообщить вам имя и пароль. Спросите так же установлен ли Firewall? Если да, попросите уточнить какие порты на нем открыты и какие протоколы разрешены: (UDP, TCP)? Уф… сколько всего!
Только не удивляйтесь, если лицо администратора примет выражение тигра под хвост которому залетел шмель и будьте готовы принять на себя все громы и молнии, а так же землетрясение, потоп, ураган и цунами – все сразу. Ой, как не любят администраторы ICQ! И на то есть веские причины! Программа с закрытой спецификацией протокола, множеством ошибок и дыр, да к тому же наследующая все привилегии запустившего его пользователя – "золотой ключ" любого хакера, вознамерившегося проникнуть в локальную сеть сквозь крепостную стену Firewall-а. Разрешать использование ICQ может либо бестолковый, либо наплевательски относящийся к безопасности администратор. Впрочем, кто не рискует…
Итак, будем считать, администратор не препятствует использованию "Яськи" и сообщает вам все необходимые сведения о настройке Firewall (Proxy-сервера). Указываем тип Proxy сервера – SOCKS 4 или SOCKS 5, переводя радио кнопку в соответствующее положение – "I am using a SOCKS 5 proxy server" или "I am using a SOCKS 5 proxy server" соответственно. Положение "I don’t use a SOCKS Proxy server on my firewall or I am using another Proxy server" ("Моя не использует SOCKS Proxy сервер на моем firewall или моя использует другой – надо полагать тип – Proxy сервера") следует выбрать если ваша локальная сеть ограждена по периметру Firewall-ом или выход в Интернет осуществляется через Proxy-сервер другого типа (интересно бы знать какого? Через типовой шлюз уровня приложений ICQ работать явно не будет – ей подавай нечто специфичное).
Настройка Firewall-а. Пейджер ICQ использует для своих нужд оба транспортных протокола – и TCP (транспортный протокол с постоянной установкой соединений), и UDP (транспортный протокол без установки соединения поддерживающий лишь посылку и получение дейтаграмм). На Firewall-е должны быть открыты следующие порты: UDP порт номер 4000 для исходящих дейтаграмм и по возможности все TCP-порты для входящих пакетов (хорошая идея – запечатлеть лицо администратора в том момент, когда его просят открыть все порты для входящих соединений – это все равно что в подъемном мосту, защищающим вход в крепость, поделать отверстие размером с сам мост). Впрочем, потребности в диапазоне портов можно и ограничить – чтобы умерить "Аськин" аппетит необходимо в графе "TCP Prot Allocation" ("Выделение TCP-портов") переместить радио копку с положения "Use dynamically allocated port numbers" ("Использовать динамическое выделение номеров портов") в котором она находилась по умолчанию, в положение "Use the following TCP listen ports for incoming event" ("Использовать следующие номера TCP-портов для установки сервера, ожидающего приема входящих сообщений") – это приведет к разблокированию двух окон ввода, задающих наименьший ("From") и наибольший ("to") номера допустимых портов – по умолчанию 2000 и 4000 соответственно. Диапазон портов следует выбирать согласно величине вашего контактного списка – для каждого абонента, с которым установлено соединение (то есть, попросту говоря, идет обмен сообщениями) необходим один порт. Т.е. в большинстве случаев пары десятков портов с лихвой хватит. При желании можно вообще избежать открытия портов на Firewall – вместо этого администратор может сделать mapping (см. "subQ:Что такое TCP/UDP mapping?") – впрочем, такой трюк не сильно повышает безопасность…
Настройка SOCKS 4 Proxy сервера: в строке "SOCKS 4 Host" ("узел SOCKS 4") графы "SOCKS 4 Server" ("SOCKS 4 Сервер") укажите адрес своего Proxy-сервера, а строчкой ниже – номер порта (по умолчанию 1080). Если значение по умолчанию не действует, уточните номер порта у администратора сети. Это лучше сделать сразу, поскольку, все равно к администратору придется обращаться с просьбой установки mapping-а (см. "subQ:Что такое TCP/UDP mapping?") – SOCKS 4 Proxy сервер не может "проксить" UDP-протокол, который необходим ICQ для работы, и его mapping приходится настраивать самостоятельно, переправляя все обращения на сервер mirablis.com по 4000 порту. Номер внутреннего порта администратор назначает самостоятельно и он может быть любым – не обязательно 4000.
Настройка SOCK 5 Proxy сервера: в строке "SOCKS 5 Host" ("узел SOCKS 5") графы "SOCKS 5 Server" ("SOCKS 5 Сервер") укажите адрес своего Proxy-сервера, а строчкой ниже – номер порта (по умолчанию 1080). Если сервер требует обязательной авторизации (это можно уточнить у администратора сети) взведите галочку "Use RFC 1929 (Cleartext) authentication for SOCKS" (Использовать открытый пароль для SOCKS аутентификации, согласно спецификации RFC 1929) – это приведет к разблокированию полей "SOCKS 5 Username" ("Имя пользователя для входа на SOCKS сервер") и "SOCKS 5 Password" ("Пароль для входа на SOCKS 5 сервер") в которые следует занести имя пользователя и пароль соответственно. Вполне возможно, придется бежать в ближайший магазин за пол-литрой для умасливания администратора – те страсть как не любят разрешать открытую передачу пароля по сети, а более изощренные способы аутентификации с зашифрованным паролем ICQ не понимает.
Родственные вопросы:
subQ:Что такое TCP/UDP mapping?
subQ:Что такое TCP/UDP mapping?
Технология "TCP/UDP mapping" позволяет клиенту локальной сети, сидящему за Proxy-сервером, принимать входящие соединения, а администратору ограничивать своих подопечных, предоставляя им доступ только к заранее оговоренным ресурсам. Кроме того, mapping-серверы очень просто программировать и разработать их может сам же администратор, написав буквально десяток строк на Perl или чуть-чуть больше на Си.
Грубо говоря, TCP/UDP mapping это до предела упрощенный TCP/UDP Proxy-сервер. Принцип его работы в общих чертах заключается в следующем – Proxy ожидает подключений от локальных клиентов по некоторому порту, а, дождавшись – устанавливает соединение с заранее оговоренным Интернет – сервером по заранее оговоренному порту, причем номера портов по обе стороны не обязательно должны совпадать. Аналогично, такой Proxy сервер может принимать входящие включения извне сети и направлять их заранее оговоренному клиенту.
Например, пусть клиенты локальной сети хотят получить доступ к серверам телеконференций находящимся вне локальной сети, где-то там, в Интернет. Скажем, это news.microsoft.com, news.relcom.ru и news.org. Администратор Proxy устанавливает mapping – все подключения к Proxy-серверу по 119 порту он будет переправлять на сервер news.microsoft.com порт 119. Пользователи, желающие читать конференции с сервера Microsoft, должны прописать в настройках своего клиента не адрес news.microsoft.com, а адрес своего Proxy-сервера, который и осуществляет такое перенаправление. То есть, для клиентов локальной сети Proxy-сервер как бы станет сервером news.microsoft.com.
Хорошо, а если кому-то потребуется обратиться еще к одному серверу новостей, скажем, news.relcom.ru – "mapping" двух серверов на один и тот же порт невозможен, т.к. Proxy не сможет понять, что от него хотят и к какому именно серверу следует переправлять пакеты. Поэтому, приходится идти на хитрость – пусть при соединении с Proxy-сервером по некоторому порту отличному от 119, т.к. этот порт уже занят, например, 666 – Proxy будет переправлять клиента на сервер news.relcom.ru порт 119. Пользователям для связи с news.relcom.ru понадобится указать в настройках программы-клиента адрес своего Proxy-сервера и порт 666 – и все будет работать нормально! Конечно, при условии, что используемое приложение допускает задание нестандартного порта для входа на сервер.