НТВ плюс 

Чем proxy отличается от nat. Как NAT или прокси реагируют на входящий пакет TCP SYN? NAT и специализированные прокси глазами сисадмина

Бывает так, что нужно срочно воспользоваться микрофоном в скайпе или записать важное сообщение, но микрофон отказывается работать. Причины данной неисправности могут быть самыми разными: будь то питомец, который прошелся по вашему компьютеру, или же системная ошибка. Нет надобности обращаться к специалистам из-за такой проблемы. Самостоятельно исправить данную неисправность очень просто. В этой статье я подробно расскажу, как включить встроенный микрофон на ноутбуке.

Причин, по которым встроенный в ноутбук микрофон может не работать довольно много. Важно правильно определить, в чем именно было дело, прежде чем пытаться что-то исправить. Вот самые распространенные проблемы:

  1. выбрано другое устройство;
  2. системная ошибка;
  3. механическое повреждение микрофона;
  4. неисправность шлейфа микрофона;
  5. загрязнение отверстия.

Причина 1: выбрано другое устройство

Пожалуй, это самая распространенная причина данной проблемы. Данные способы подойдут для всех версий операционных систем, включая Windows 7, Windows 8 и 10.

Способ 1: ручная настройка микрофона на ноутбуке

  1. Для этого в нижней правой части экрана найдите значок динамика.
  2. Кликните по нему правой кнопкой мыши и в выпадающем меню нажмите на пункт «записывающие устройства».
  3. В открывшемся окне есть изображения микрофонов. Найти нужный очень просто. Достаточно постучать или поговорить в специальное отверстие на корпусе. Напротив нужного устройства уровень будет прыгать в такт шуму.
  4. Затем необходимо выбрать найденный микрофон в качестве основного, нажатием на клавишу «ОК»

В этом же меню можно настроить уровень громкости микрофона на ноутбуке. Очень часто он стоит на нуле из-за этого, пользователям и кажется, что он не работает.

Способ 2: автоматический поиск проблем

  1. Для этого нужно открыть панель управления.
  2. Затем кликнуть на раздел «Поиск и устранение проблем» в категории «Система и безопасность».
  3. В разделе «Оборудование и звук» выбираем «Устранение неполадок звукозаписи».
  4. Далее следуем инструкциям мастера устранения неполадок. Все неисправности будут выявлены и устранены.

Причина 2: системная ошибка

Из-за непредвиденных системных ошибок или вирусов настройки микрофона могут сбиться, и нужно будет настраивать все заново. Необходимо воспользоваться одним из описанных выше способов для устранения этой неполадки. Для профилактики нужно чистить компьютер от нежелательных программ, регулярно обновлять Операционную Систему и иметь антивирус с защитой в реальном времени.

Причина 3: механическое повреждение

Часто встречающаяся причина. Дело в том, что микрофон в отверстии ничем не защищен и от удара или от попадания твердого предмета он может выйти из строя. Тогда во вкладке «Записывающие устройства» при постукивании по отверстию индикатор уровня будет оставаться на нуле или будет всегда на максимуме. Для решения данной проблемы можно обратиться в специализированный сервисный центр или купить выносной проводной микрофон.

Причина 4: неисправность шлейфа

Микрофон подключен к плате по средствам шлейфа с разъемом. От ряски разъем может отщёлкнуться и контакт нарушиться. Нужно обратиться в сервис или же купить отдельное устройство.

Причина 5: загрязнение отверстия

Очень банально, однако это то, на что не обращают внимание многие пользователи. Отверстие для микрофона часто расположено в неудобном месте. Грязь с рук может попадать туда и полностью заблокировать проход звуковых волн. В этом случае микрофон или вовсе не функционирует или работает очень тихо. Нужно очистить отверстие, используя ватную палочку или пылесос и впредь следить за его чистотой.

Рассмотрим типовой вариант - внутренняя сеть подключена через сервер доступа к Интернет и использует один внешний "белый" IP-адрес (см. вариант применения в разделе "Офисная сеть ").

Задача обеспечения доступа в Интернет из внутренней сети решается, как правило, с помощью NAT или прокси-сервера. Каждый подход имеет свои достоинства и недостатки.

Принцип работы NAT - это простая трансляция IP-адресов и портов в пакетах при прохождении через сервер. Для доступа через NAT не требуется никакая настройка клиентских программ - служба прозрачно транслирует все исходящие запросы наружу. Также этот подход отличает максимальная производительность и не требовательность к ресурсам сервера. Но NAT не позволяет приложению открывать входящие соединения. Это накладывает ограничения на некоторые протоколы, например IRC.

Traffic Inspector использует службу NAT Windows. Это называется ICS (Internet Connection Sharing) или RRAS (Routing and Remote Access Server) для серверных версий системы.

NAT может работать в режиме трансляции портов и адресов. Если используется один внешний адрес, то применяется трансляция портов. Но у провайдера можно дополнительно получить группу адресов и тогда через NAT какой-то внешний адрес может быть назначен на внутренний. Это удобно для случая, когда внутри сети находятся какие-то сервера и требуется прозрачная трансляция портов без их замены. Но всегда имеется возможность публикации наружу внутренних серверов даже на единственный внешний адрес.

В чистом виде NAT от Windows используется мало, так как там практически отсутствует возможность разграничения доступа и контроля трафика.

Прокси-сервер работает на уровне протоколов приложений и требует соответствующей поддержки со стороны клиентских программ и их настройки. Через него можно работать по протоколам HTTP или FTP. Также имеется специальный протокол прокси-серверов SOCKS, через который может работать любое приложение, использующее TCP. Через SOCKS можно открывать как исходящие, так и входящие соединения, так что тут снимаются проблемы NAT. Единственное ограничение - это необходимость поддержки SOCKS со стороны клиентских программ.

При работе с HTTP для экономии трафика прокси-сервера используют кэширование (временное сохранение) закачанных объектов, которые могут использоваться при повторных запросах. Использование кэширования может увеличить скорость доступа при загруженной сети Интернет.

Также с помощью прокси-сервера можно реализовать фильтрацию на уровне приложения - например, запретить доступ к какому-то конкретному ресурсу на сервере или сделать разграничение по контенту данных.

В составе Traffic Inspector имеется полнофункциональный HTTP/FTP/SOCKS прокси-сервер. Реализована гибкая фильтрация, имеется кэширование и возможность ограничения скорости работы. По функциональным возможностям он ничуть не уступает другим прокси-серверам. При работе через HTTP доступна работа с методом CONNECT, что позволяет работать с SSL, а также с помощью этого метода возможна работа с FTP, электронной почтой и другими приложениями, которые это поддерживают. Также имеется возможность работать с FTP через HTTP - при этом клиент использует HTTP (обычный браузер), получая данные с FTP-сервера в виде страниц.

Есть еще одна возможность работать с Интернет из внутренней сети - это получить у провайдера IP-подсеть, сконфигурировать сервер доступа как роутер и раздать клиентам "белые" адреса. Traffic Inspector в таком варианте также сможет работать. Но этот подход мало пригоден прежде всего из-за проблем с безопасностью. Но маршрутизация сети может потребоваться при организации DMZ (т.н. "демилитаризованной зоны") для размещения публичных серверов (см. вариант применения в разделе "

/05.07.2004 20:43/

Последние годы среди российских сетевых администраторов стихийно возрастает мода на FireWall и NAT . Моё отношение к этим технологиям пользователи Eserv знают еще с середины 90х годов, но иногда такие вопросы о FireWall / NAT задаются новичками, и приходится повторяться. Поэтому около года назад я написал отдельную статью о FireWall , а сегодня настала очередь NAT.

Эпиграф

Добавлено 28.12.2005 . Хорошее резюме проблемы NAT сделали Google : "NAT devices, increasingly popular in homes and offices, allow multiple machines to share a single Internet address. Consequently, it becomes more and more difficult for applications such as voice chat, which require peers to directly address each other, to make a peer-to-peer connection reliably." (NAT-устройства, популярность которых растет в домах и офисах, позволяют нескольким машинам совместно использовать один интернет-адрес. В результате таким приложениям как голосовой чат, требующим прямой адресации сторон, все сложнее и сложнее создавать надежные соединения точка-точка.)

Оглавление документа

История NAT

Сначала несколько слов об истории появления необходимости в проксировании / гейтировании / туннелировании в интернете, тогда яснее станут возможности разных подходов и их "иерархия". Как известно, нехватка IP-адресов в 4-байтовом адресном пространстве прогнозировалась еще в начале 90х годов (плюс нехватка денег на аренду адресных блоков в некоторых компаниях . Поэтому уже в марте 1994 г договорились об адресном "сегментировании" общего пространства - выделении для локальных сетей отдельных диапазонов IP-адресов и исключение этих IP-адресов из использования в интернете (http://www.ietf.org/rfc/rfc1597.txt March 1994 Address Allocation for Private Internets ; цитата о назначении этого документа "Авторы надеются, что использование этих методов приведет к значительной экономии при выделении адресов"). Это решение позволило выделять компаниям небольшие блоки IP-адресов - для их интернет-серверов, а внутри ЛС IP-адреса для собственных нужд выделялись самими компаниями из диапазонов для локальных сетей. В результате интернет-серверы компаний (почтовые и www/ftp) были легко доступны как из интернета, так и из ЛС, и внутри ЛС компьютеры без проблем связывались по таким же IP-протоколам. Но это решение воздвигло барьер между локальными сетями и интернетом: т.к. один и тот же IP-адрес мог использоваться в разных ЛС, и т.к. по этой причине в интернете перестали маршрутизировать пакеты на адресные блоки, выделенные для ЛС. Т.е. фактически "физический барьер" (без перерубаний проводов, чем развлекались в российских банках после первых взломов, и без установки FireWall , чем увлекаются сейчас). Сети стали изолированными, как изолированы задачи в современных операционных системах - у каждой своё адресное пространство. Этот барьер не представлял проблемы для почты, т.к. почтовые серверы предприятий ставились на границе сетей и были видимы и из интернета, и из ЛС. А вот с доступом из ЛС к внешним ресурсам - к ftp и еще только набирающим в те годы популярность http-серверам начались проблемы. Если раньше с любого компьютера можно было напрямую взаимодействовать с сервером, то теперь эта возможность осталась у компьютеров только с реальными интернет-адресами, т.к. в какую ЛС слать ответ на IP-пакет, у которого в обратном адресе стоит локальный - роутер определить не сможет.

Простейшее решение этой задачи - подмена обратного адреса на границе сетей - лежало на поверхности и не замедлило опубликоваться: в мае 1994 г., т.е. через два месяца после "раздела сетей" предложили спецификацию NAT: http://www.ietf.org/rfc/rfc1631.txt The Network Address Translator (NAT) May 1994 Авторы анонсировали это как "short-term solution", т.е. временное решение указанной проблемы, эдакий "хак", пока не получат распространение нормальные решения. Но, как известно, ничего не бывает столь постояным, как временное IPv6 вопреки ожиданиям быстро не прижился, и все прошедшие 10 лет мы были свидетелями все новых и новых боев на границах ЛС и интернета. NAT получил распространение, т.к. никакого другого приемлемого решения этой проблемы в те годы не было: FTP-клиенты и HTTP-клиенты (браузеры) не успели адаптироваться под под измененную картину мира, не могли работать из ЛС с внешними ресурсами, поэтому чтобы сделать для них границу прозрачной, их просто программно "обманывали" с помощью NAT - все IP-пакеты, адресованные из ЛС наружу, подвергались простейшей обработке на границе: замене обратного IP-адреса на реальный адрес "пограничного" компьютера, и обратной замене во входящих пакетах. Кроме того обычно заменялся и номер порта ЛС-источника, т.к. с разных машин в ЛС пакеты могут исходить с одними и теми же номерами портов. Т.е. транслируются не только IP-адреса, но и номера портов (иногда порт-трансляторы называют отдельной аббревиатурой PAT). В условной классификации NAT подразделяют на "статические, динамические и маскарадинг (masquerading)", но на практике применяется в основном третий тип, он позволяет через один реальный адрес обслуживать тысячи соединений из ЛС (в идеале), трансляция портов при этом используется всегда. На NAT-компьютере или роутере+NAT выделяется диапазон портов, используемых для трансляции, например с номерами больше 60000 (чтобы быстрее отличать эти порты от выделенных под собственные нужды этого компьютера) и динамическая таблица текущих сессий/отображений адресов. Каждый проходящий пакет сверяется с этой таблицей по и порту и производятся соответствующие подстановки. Технология настолько проста, что сейчас уже все реже можно встретить роутер или кабельный модем без встроенного NAT (и FireWall , столь же примитивного как NAT), причем NAT уже можно обнаружить даже в hub"ах c ценами от $40. Не говоря уж о "бесплатном" NAT, входящем в состав нескольких последних версий Windows под именем "connection sharing " и "совместное использование соединения ". Именно доступность, простота понимания/использования и нетребовательность к клиентскому софту, сделали NAT заслуженно популярным.

NAT "глазами" интернет-программ

Если бы на практике все было так просто, то было бы неинтересно Но, конечно, как бывает и с любым другим программным трюком, в NAT сразу же стали вылезать разнообразные неприятные побочные эффекты. На момент появления NAT одним из самых популярных протоколов был FTP, и именно этот протокол стал для NAT первым неперевариваемым протоколом. Это выявило проблему, которая так и не была хоть сколько нибудь успешно решена в NAT за эти 10 лет. И в общем случае она не может быть решена в рамках NAT, могут быть только подгонки под конкретные протоколы, но эти подгонки нельзя считать надежным решением. Проблема эта состоит в том, что в некоторых протоколах, среди которых старейшим является FTP, передается IP-адрес клиентской машины, и этот IP-адрес используется сервером для передачи данных клиенту. Поскольку в случае с NAT клиентская программа, работающая из ЛС "обманута" NAT"ом, она может передать серверу только свой собственный локальный IP-адрес, соединиться с которым внешний сервер не сможет из-за невидимости локальных сетей из интернета. Другими примерами могут служить протоколы ICQ, MS NetMeeting , RealAudio и многие другие протоколы, разработчики которых видимо сидели в сетях без
NAT NAT может предложить только одно решение такой проблемы - основываясь на номерах портов угадать конкретный транслируемый протокол и начать следить за содержимым IP-пакетов. Когда в них встречается FTP-команда PORT, в которой указывается :порт локального клиента (текстовая команда в теле пакета, а не в заголовке IP-пакета), то заменять не только заголовки, но весь пакет, с пересчетом контрольной суммы и организацией прослушки еще одного входящего порта. К сожалению для NAT, TCP-протокол, в котором передаются команды FTP-протокола, является поточным протоколом, организованным над - команда PORT при попадании на IP-уровень может оказаться разбитой на 2 пакета (а то и более, в зависимости от FTP-клиента и буферизации в ОС). Поэтому для надежного обнаружения места подмены NAT"у придется реконструировать исходный TCP-поток, буферизировать и пересобирать пакеты. К "реконструкции протоколов" в NAT мы еще вернемся, а пока просто отметим многоярусный уровень потенциальных ошибок и ненадежностей в этом процессе. На практике это приводит к тому, что стандартный режим FTP с использованием команды PORT через NAT как правило НЕ работает.

Поэтому "проблему NAT" в FTP-протоколе приходится обходить особым образом в FTP-клиентах или в еще одном промежуточном специализированном FTP-прокси. В FTP-клиенте для этого нужно переключиться в т.н. "пассивный режим" - использовать вместо команды PORT команду PASV. PASV просит FTP-сервер открыть дополнительный порт у себя и сообщить клиенту его :порт. Клиент после этого соединяется с указанным (NAT его еще раз обманывает-транслирует) и сессия удается. Кроме необходимости поддержки PASV-режима в FTP-клиенте (в стандартном ftp.exe её нет), при этом требуются и некоторые усилия со стороны администратора FTP-сервера - особенно если он тоже частично загорожен Firewall"ами и NAT"ами (как разработчик FTP-сервера для Eserv знаю эти проблемы не по наслышке). В общем, здесь NAT не помогает соединяться, а мешает.

Теперь о реконструкции протокола внутри NAT для "прозрачного" для клиента обхода проблемы. Те немногие NAT, которые это умеют (хотя на практике тоже скорее декларируют, чем умеют , фактически поднимаются на один сетевой уровень вверх - вместо простейшего форварда пакетов с трансляцией адресов в заголовке они начинают заниматься тем же, чем занимается TCP-стек - сборкой TCP-потока из пакетов. Таким образом они превращаются из переразвитого роутера в недоразвитый прикладной TCP-прокси. В данном случае в FTP-прокси или в FTP-гейт. Недоразвитый потому, что клиент не знает об этом прокси, а NAT в свою очередь продолжает угадывать протокол и заниматься задачей, которая неудобна для решения на его уровне (уровне IP-пакетов).

Намного проще эта задача решается, если вместо NAT или в дополнение к нему сразу использовать специализированный прокси (FTP gate) или универсальные TCP-прокси типа Socks или в крайнем случее httpS (этот крайний случай тем не менее сработает лучше чем NAT). Они изначально работают на TCP-уровне и не обманывают FTP-клиента, а сотрудничают с ним. Отпадают сразу три слоя проблем: FTP-клиент может использовать любой режим - активный или пассивный (в httpS только пассивный, как и в NAT), нет нужды угадывания протокола и двойной сборки TCP . Кроме того, у админа появляется больше возможностей влиять на процесс (об этом позже).

Если клиентская программа не умеет работать через спец-прокси (таких практически не осталось, но будем говорить о худших случаях), то при использовании Socks-прокси работу клиента также можно сделать прозрачной с помощью программ SocksCapture или отечественной FreeCap . Прозрачность границы - это всегда обман, но SocksCapture или FreeCap перехватывают не IP-пакеты, а обращения программы к ОС, поэтому они всегда точно знают, а не вычисляют по потоку пакетов, какое именно действие хочет совершить программа, и соответственно перенаправляют эти действия через Socks-прокси.

NAT vs Socks

Раз уж зашел разговор о Socks, надо сказать несколько слов об этом прокси-протоколе. Тем более что исторически Socks был следующим после NAT средством преодоления границы между ЛС и интернетом: первая обзорная статья "what is socks" была опубликована в октябре 1994 г., вскоре появилась спецификация Socks4 (предыдущие "версии" не применялись ни в каких продуктах) http://www.socks.nec.com/protocol/socks4a.protocol и только к 5й версии в марте 1996 года созрел для публикации в ietf в качестве RFC: http://www.ietf.org/rfc/rfc1928.txt. Есть русская версия этого документа - перевод выполнил Александр Горлач, который тогда (97й и 98гг) работал в нашей фирме и участвовал в создании Eserv /2, см. страницу Socks5.

Socks преодолел все ограничения NAT, плюс добавил как минимум три удобных средства, позволяющих не только "проксировать" практически любой TCP и UDP протокол, но и улучшить контроль над использованием интернета из ЛС:

  1. Socks не только обслуживает исходящие соединения, но и позволяет создавать слушающие входящие сокеты на прокси-машине (метод BIND) по запросу прокси-клиента - это требуется как раз для FTP и подобных многосвязных протоколов.
  2. Socks4a и Socks5 позволяют снять с клиента задачу разрешения доменных имен на клиенте, а делать это прямо в прокси. Т.е. машине внутри ЛС становится ненужным DNS-сервер или DNS-маппинг (через NAT или спец.UDPMAP), с админа снимается одна "галочка" его забот, плюс за счет кэширования DNS на сервере клиент работает быстрее.
  3. Socks5 поддерживает различные варианты явной аутентификации и авторизации клиента. В NAT можно было отличать своих от чужих только по .
Но Socks хоть и повысил удобство работы по сравнению с NAT, остается универсальным "программируемым маппингом". Часть проблем NAT осталось в нем нерешенными. И они не могут быть решены на низком уровне без вникания в детали конкретного проксируемого протокола. Так же как, например, телефон способен передать человеческую речь, но не способен её понять и отфильтровать брань Поэтому те администраторы, которые хотят полного контроля над происходящим в его сети, используют специализированные прокси.

NAT и специализированные прокси глазами сисадмина

Сначала опять небольшой экскурс в историю. Протокол HTTP был разработан в начале 90х (так называемая "версия 0.9"), и к середине 90х стал "killer app" интернета - тем, ради чего к интернету стали подключаться не только ученые и военные, но и "простые коммерсанты и обыватели". Соответственно назрела необходимость стандартизации. В мае 1996 года была выпущена спецификация HTTP/1.0 под знаменательным-победоносным номером RFC:1945. Авторы спецификации уже принимали во внимание новые реалии интернета, в т.ч. необходимость проксирования протокола для ЛС. К тому же на практике HTTP существовал уже не первый год и "опыт проксирования" имел. Поэтому в документе были сделаны необходимые определения и замечания о прокси, шлюзах и туннелях. И фактически там был определен не только сам HTTP-протокол (с точки зрения обычного веб-сервера), но и описаны протоколы HTTP-proxy и HTTPS-proxy. Метод "CONNECT", введенный в протокол HTTP специально для обеспечения возможности соединения с secure HTTP-серверами через прокси, тем не менее позволял не ограничиваться 443м портом, а указывать любой порт для соединения. Таким образом в лице HTTPS прокси мы получаем еще один "программируемый TCP-маппинг" для любого протокола, хотя и с намного более ограниченными возможностями, чем Socks5. Совсем другое дело HTTP proxy для "родного" ему HTTP-протокола. Его он может обрабатывать с полным знанием дела - кэшировать, фильтровать по URL и контенту, ограничивать, маршрутизировать, авторизовать, и т.д. Часто эти действия требуют таких нетривиальных действий на уровне TCP и других компонентов ОС, что практически невозможны на пакетном уровне NAT или слепом отображении Socks.

То же самое с любым другим прикладным протоколом, для которого существуют специализированные прокси - они всегда на порядок более управляемые, чем универсальные низкоуровневые. Например, многие POP3-прокси позволяют фильтровать спам, например PopFile (хотя намного более правильно фильтровать спам не на прокси, а на SMTP-сервере). Socks и NAT для этого потребовались бы особые умения по вниканию в передаваемый протокол, т.е. фактически "эмуляция" POP3-прокси не слишком удобными для этого средствами.

Поэтому использование Socks или NAT для работы с теми протоколами, для которых существуют специализированные прокси (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) или общепринятая архитектура промежуточных серверов (SMTP, POP3, IMAP, DNS) можно считать вынужденным неоптимальным решением. Вынужденным - либо от невозможности использования нужного типа прокси по организационным причинам (некуда поставить нужный вид прокси, или тип подключения не предусматривает наличия ни одного реального IP-адреса, как в случае с интернетом через GPRS или вариантов домовых сетей - в этих случаях NAT или "принудительный HTTP-прокси" уже стоят на стороне провайдера), либо от недостаточной информированности ответственных лиц, в т.ч. админов. Финансовые ограничения не принимаю во внимание, т.к. существует масса вариантов бесплатных или очень дешевых прокси для всех этих протоколов.

В некоторых случаях использование Socks5 вполне оправдано - например, для ICQ и других месенжеров. Для этих протоколов спец-прокси просто не разрабатываются, т.к. они почти незаметны на общем фоне использования сети. При отсутствии в ЛС почтового сервера или pop3/smtp-прокси следующим кандидатом будет также Socks5, хотя его поддержка есть не во всех почтовых клиентах, а в некоторых имеет неочевидные особенности (см. Mozilla ThunderBird).

При переборе вариантов NAT будет "последней инстанцией" - на случай, если не нашлось ничего лучше, или если NAT поставлен провайдером изначально - в кабельном модеме, маршрутизаторе, мобильном подключении (в эти железки ставится именно NAT, а не спец-прокси для популярных протоколов, благодаря предельной простоте его базовой реализации: исходник аналогичного по устройству NAT UDPMAP plugin в Eproxy имеет размер всего 4Кб). Часть протоколов работать не будет, управлять работой будет сложно. Но в таких предельных случаях лучше хоть как-то работать, чем вообще не работать

Вот такое развернутое пояснение к известной моей позиции последних 8 лет - "в Eserv никогда не будет NAT" В подавляющем большинстве случаев NAT либо вам не нужен, либо он у вас уже есть в качестве наказания за выбор провайдера А для ознакомления с NAT можно использовать встроенный в Windows connection sharing, он работает именно как NAT.

См. также "костыль" для NAT на сайте Microsoft: NAT traversal - преодоление NAT путем адаптации приложений , конфигурация NAT/Firewall через UPnP . Если словосочетание NAT traversal вы слышите впервые, то это потому что разработчики предпочитают Socks5 вместо костылей к патчам, и эта инициатива не получила "поддержки кодом". Но статья хороша своими картинками (в отличие от моей и еще одним независимым описанием проблем NAT.

NAT, ICS уже встроен во все новые версии Windows



Во всех версиях Windows, выпущенных с 1999 года, NAT входит в комплект. Сначала под именем ICS (Internet Connection Sharing - общий доступ к соединению), а позже уже под своими именем NAT. Вот диалог включения NAT в Windows 2003 (через "Маршрутизацию и удаленный доступ" system32rrasmgmt.msc).


В Windows XP NAT/ICS включается в свойствах интернет-соединения.


Если выдается сообщение "Не удается разрешить общий доступ. Ошибка: 1722: Сервер RPC недоступен." ("Cannot enable shared access. Error: 1722: The RPC server is not available."), то скорее всего у вас остановлен или запрещен сервис DHCP-клиент, нужно его запустить до включения ICS.

NAT глазами сисадмина провайдерских Linux

(Добавление от 6 июля 2004 - первый отклик на статью. Как и в статье про FireWall , предоставим слово настоящему сисадмину

Цитата Если сравнивать работу через NAT с реальным , то пока проблемы с NAT у меня были только с голосом, видео и передачей файлов в программах типа MSN Messenger. Возможно в каких-то реализациях NAT"а есть также проблемы с активным ftp, соединением с внешними VPN-серверами и т.п., но при работе через NAT в Linux"е (при соответсвующих настройках) с этим проблем нет. Преимущество NAT в данном случае в экономии IP-адресов и файрволе.

Если сравнивать NAT с прокси (как способ выхода в Интернет, т.е. перенаправление запросов, не рассматривая функции кэширования, анализа URL и т.п.), то через NAT работает больше приложений и протоколов (все ); для NAT не требуется специальных настроек со стороны пользователя; прокси более требователен к оборудованию. Прокси обычно не обеспечивают функциональности Destination NAT (DNAT), хотя в Есерве у тебя частичного подобия DNAT можно добиться с помощью tcp/udp-маппинга. Конец цитаты.

Эта цитата показывает, что у провайдеров тоже требования сильно отличаются от админов на предприятиях.

BackLinks
Articles
FireWall
MxServer
NCSI
WhatIsProxyServer

0

В некоторых системах обмена сообщениями два клиента обмена сообщениями отправляют/принимают пакеты непосредственно друг от друга в чате или голосовом вызове. Я думаю, что основной механизм (например, TCP): эти клиентские программы открывают прослушивающий TCP-сокет и сообщают серверу обмена сообщениями/координирующей их IP/PORT пару. Затем клиентские программы извлекают IP/PORT другой стороны из сервера обмена сообщениями/координации. И один из них (допустим, A) затем инициирует TCP с другим (скажем B) с полученной парой IP/PORT B.

Когда пассивный клиент B (который ожидает пакет TCP SYN) не за NAT или прокси, это прекрасно. Но если B находится за NAT или прокси-сервером, то пара IP/PORT фактически является общедоступным сетевым интерфейсом NAT или прокси.

Итак, мой вопрос: когда NAT или прокси получает TCP SYN, какова его реакция? Как они передают TCP SYN в соответствующий хост/процесс за ним?

  • 2 ответа

    • Сортировка:

    Активность

0

Я сомневаюсь, что ваше первоначальное предположение верно. Скорее всего, они оба открывают активные подключения к серверу, а сервер маршрутизирует данные между ними. Это намного проще, и проблемы, которые вы описываете, исчезают.

0

Этот вопрос был явно спросил давно, но до сих пор...

чат и голосовые/видео вызов, как правило, обрабатываются совершенно по-разному. В случае чата вы, вероятно, будете использовать протокол XMPP, где оба конца будут подключаться к серверу и обмениваться данными через него. XMPP находится на TCP на уровне 4, поскольку надежность в этом случае выше приоритета, чем латентность. Поскольку клиенты - это те, которые открывают и поддерживают соединение, в этом случае у вас не будет проблем с NAT.

  • части, где вы обсуждаете сеть (IP-адрес и порт) и деталь кодеков, необходимую для сигнализации настройте вызов (известный как SDP - протокол описания сеанса)
  • медиа-часть, где вы эффективно обмениваетесь голосом/видеоконтентом между двумя абонентами.

Сигнал обычно проходит через TCP с использованием протоколов более высокого уровня, таких как SIP (Session Initiation Protocol). Это сообщение будет проходить через сервер. Средства массовой информации проходят через UDP с использованием протоколов более высокого уровня, таких как RTP (протокол передачи в реальном времени), и эта часть обмена сообщениями, как правило, проходит одноранговое соединение. Один порт UDP может использоваться как для передачи, так и для приема трафика для одного голосового/видеоканала. Кроме того, вы, вероятно, захотите получить информацию о качестве звонка во время вызова, чтобы вы могли, например, уменьшите используемую полосу пропускания, чтобы избежать/уменьшить потерю пакета. Для этой цели вы должны использовать протокол RTCP (протокол управления транспортным средством в реальном времени). В этом случае обход NAT имеет решающее значение! Поскольку ни один из клиентов не знает свои общедоступные IP-адреса, вам нужен сервер в вашей внутренней сети (в общедоступном Интернете), который мог бы сказать «как вы видите снаружи», то есть за NAT. В частности. Мир WebRTC этот сервер знает ICE. После того, как партнер узнает, как это видно из Интернета, он будет размещать эту информацию внутри части SDP сигнального сообщения, чтобы другой конец мог дойти до нее через Интернет. Имейте в виду, что маршрутизатор, который выполняет NAT, может также потребовать некоторые дополнительные настройки для отслеживания используемых портов UDP для голоса и видео (для NAT-back трафика из Интернета вам).

Наконец, в этих случаях используются другие решения, но это зависит от вашей настройки. Если вы пишете программное обеспечение для конечного пользователя, тогда будут применяться предыдущие объяснения.Однако, если вы пишете программное обеспечение для корпоративного рынка, такие решения, как дополнительный сервер (известный как EDGE) на границе вашей корпоративной сети, будут распространенным подходом.

Я могу написать об этом часами, но этого должно быть достаточно для начала... :)

Соединение ПК, подключенного к локальной сети, с интернетом может осуществляться с помощью таких технологий, как NAT и Proxy. Что они собой представляют?

Что такое NAT?

NAT - это технология, позволяющая подключать ПК, объединенные в локальную сеть, к интернету при задействовании механизма трансляции IP-адресов (либо портов) в сетевое пространство за пределами ЛВС. Каждый ПК, подключенный к локальной сети, осуществляет запросы в службу NAT, которая преобразует их в те, что адресованы тем или иным сервисам интернета.

Использование технологии NAT, как правило, предполагает задействование отдельного сетевого устройства - маршрутизатора, сервера или же, например, межсетевого экрана.

Даже если к интернету посредством технологии NAT подключается несколько компьютеров одновременно, онлайновый сервер видит запросы только с одного IP-адреса - устанавливающегося на устройстве, в котором реализованы алгоритмы NAT.

Есть две основные разновидности рассматриваемой технологии - Source NAT и Destination NAT.

Первая предполагает замену адреса, установленного для источника пакета, при передаче данного пакета на компьютер назначения в интернете и, соответственно, замену адреса, установленного для ПК назначения в локальной сети, при отправлении пакета обратно. При необходимости меняться могут также номера портов ПК в ЛВС.

Технология Destination NAT предполагает трансляцию пакетов, направляемых в ЛВС из внешней среды - например, с онлайнового сервера, на конкретный ПК, имеющий локальный IP-адрес, который недоступен для соответствующего онлайнового сервера.

Основное преимущество применения схемы подключения ЛВС к интернету через NAT - централизация настроек соответствующей службы. Нет необходимости выставлять какие-либо специальные опции на каждом из ПК, подключенном к локальной сети.

Что такое Proxy?

Proxy - это технология, которая позволяет подключать ПК, объединенные в сеть, к тем или иным онлайновым сервисам через специальный шлюз, задействующийся отдельными приложениями. То есть для подключения ПК, которые входят в состав ЛВС, к proxy-серверу на каждом из них необходимо выставить настройки соединения. Технология Proxy - это, по сути, программная служба, загружаемая на отдельном сервере ЛВС или на одном из серверов интернета.

Компьютеры, подключенные к ЛВС, запрашивают доступ к онлайн-ресурсам не напрямую, а через IP-адрес и порт proxy-сервера. Данная концепция предопределяет наличие некоторого сходства между Proxy и NAT в том смысле, что онлайновый сервер направляет контент по запросу отдельных ПК на общий IP-адрес, прописанный в настройках proxy-сервера. Конечно, proxy-серверы в некоторых случаях могут устанавливать для подключаемых ПК уникальные внешние IP-адреса - но практически исключено их совпадение с оригинальными IP-адресами, под которыми компьютеры зарегистрированы в ЛВС.

Можно отметить, что существуют чисто «онлайновые» proxy-серверы, которые используются как раз таки в целях намеренной маскировки IP-адресов компьютеров, подключающихся к интернету. Принцип их работы в целом схож с тем, что характеризует функционирование proxy-серверов, устанавливаемых в ЛВС.

Одно из главных преимуществ использования технологии Proxy - возможность осуществлять кеширование онлайнового контента (сохранение в памяти сервера элементов посещенных веб-страниц, загруженных файлов), что позволяет ускорять доступ к интернету с отдельных ПК. Другие преимущества Proxy - в возможности:

  • проводить контроль над доступом отдельных пользователей ЛВС к интернету, фильтрацию контента и адресов сайтов,
  • устанавливать на proxy-серверах антивирусный софт, осуществляющий анализ исходящего и входящего трафика, что позволяет значительно повысить безопасность сети.

Технология Proxy рассматривается многими специалистами как более функциональная, чем NAT, поскольку позволяет внедрить широкий спектр алгоритмов управления сетевым доступом на программном уровне.

Сравнение

Главное отличие NAT от Proxy - в технологических принципах обеспечения одновременного доступа в интернет нескольких ПК, находящихся в составе ЛВС.

Если говорить о NAT, то данный стандарт управления сетевыми подключениями предполагает применение относительно более простых алгоритмов - когда адрес ПК, отправляющего пакет в интернет, меняется на адрес NAT-устройства, что позволяет последнему получить ответный пакет и доставить его по назначению. Корректировка отправляемого и получаемого пакетов при этом не осуществляется.

Технология Proxy предполагает использование более сложных механизмов обеспечения обмена пакетами между ПК, находящимися в ЛВС, и онлайновыми серверами. Так, например, при задействовании proxy-сервера контент может кешироваться, фильтроваться, проверяться на наличие вирусов.

Определив, в чем разница между NAT и Proxy, зафиксируем основные выводы в небольшой таблице.

Таблица

NAT Proxy
Что между ними общего?
Обе технологии используются в целях организации одновременного подключения к интернету нескольких компьютеров, объединенных в локальную сеть
Онлайновые серверы получают запросы от IP-адресов NAT-устройства или proxy-сервера, фактически не совпадающих с IP-адресами компьютеров, на которых формируются данные запросы
В чем разница между ними?
NAT-устройство меняет адрес ПК, отправляющего пакет в интернет, на свой (или прописанный в настройках), не изменяя структуры запроса, после чего, получив пакет от онлайнового сервера, доставляет его по назначению также без изменений Proxy-сервер, получив запрос от ПК, отправляющего пакет в интернет, перенаправляет его на онлайновый сервер через установленный IP-адрес, после чего, получив пакет, доставляет его по назначению без изменений либо откорректировав с помощью фильтров (при необходимости - проверив антивирусным модулем)
Технология не требует прописывания дополнительных сетевых настроек на отдельных ПК в рамках ЛВС Технология требует настройки программ, используемых для доступа в сеть, на каждом из ПК в ЛВС