Как да се премине IPSec трафик през ISA Server

2. IPSec NAT Traversal

Добре известен факт е, че протоколът IPSec не е проектиран като се има предвид съществуването на NAPT. Използването на IPSec протокол обикновено не е проблем в шлюз до шлюз (шлюза до врата) VPN сценарий, тъй като вратите на VPN, инсталирани на ръба на мрежата, за да се сдружават. Въпреки това, един от най-много популярни VPN-и приложения е да се осигури отдалечен достъп до корпоративна интранет. Днес NAPT-и широко разгърнати в домашни шлюзове, както и на други места може да бъдат използвани от домашни потребители. Резултатът е, че IPSec-на NAPT несъвместимости са се превърнали в основна пречка за разгръщането на IPSec в клиент-шлюз (клиент-шлюз) VPN сценарии.

Описание на точните технически подробности за известни несъвместимости между NAPT и IPSec протоколи е извън обхвата на тази статия. Ако се интересувате от това ниво на детайлност, трябва да прочетете IETF Информационна RFC 3715 «IPSec-NAPT изисквания за съвместимост» на (изисквания IPsec-NAT съвместимост), написани от Бернар Adobe (Bernard Абоба) и Уилям Диксън (Уилям Диксън) на Microsoft.

Жалко е, че двете отлични статии (от Microsoft TechNet Излъчване в интернет) «IPsec и NAT-T: И накрая, в хармония? (Ниво 400) »(IPsec и NAT-T :? Накрая в Harmony (Ниво 400)) и« IPsec Demystifying (Ниво 400) »(Demystifying IPsec (Ниво 400)), предоставени от Стив Райли (уебсайт Стив Райли), вече не е Microsoft Излъчване в интернет на място. Въпреки това, на интернет страницата на Стив Райли (уебсайт Стив Райли) Трябва да бъдете в състояние да намери отлично PowerPoint презентация «IPsec и NAT: И накрая в хармония» (уебсайт Стив Райли би трябвало да можете да намерите отлични PowerPoint презентация IPsec и NAT: И накрая в хармония.

За да активирате въвеждането на IPSec в клиент-шлюз (клиент-шлюз) VPN сценарий, IETF накрая разработва приложение, наречено NAT Traversal. Тъй като една от основните приложения на IPSec е отдалечен достъп до корпоративни Интранет мрежи, NAT-T разтвор трябва да поддържа преминаване през устройството за NAPT или режим IPSec тунел или L2TP върху режим IPSec транспорт. Това включва подкрепа за преминаване (пропускане) повече от едно устройство NAPT между отдалечения клиент и шлюза VPN. Основни елементи на разтвор за NAT Traversal:

  • Използването на IPSec AH протокол не се поддържа.
  • Съвпадение NAT Traversal-и IKE.
  • UDP капсулиране (образуване на опаковка) IPSec пакети.

2.1. Използването на IPSec AH протокол не се поддържа

Забележка: Променливите полета в заглавната част на IP са вид услуга (вид услуга) (TOS), отместване на фрагмент (фрагмент офсет), Знамена (флагове), Време за живеене (живот време) (TTL), IP хедър контролна (контролна IP глава).

2.2. NAT Traversal в хармонизирането IKE

IETF RFC 3947, "Хармонизиране на NAT-Traversal в IKE» (Договаряне на NAT-Traversal в IKE) описва как да се намери подкрепа за NAT Traversal в IPSec Силите, как да се открие една или повече NAPT устройство по пътя (по пътя), и как да се съвмести използването на UDP капсулиране на IPSec пакети през блоковете NAPT. Това се прави чрез определяне на някои промени и разширения и допълнения в протокола IKE (Internet Key Exchange-Internet обмен ключ). За да разберем по-добре какво се случва зад кулисите, нека мине през процеса на преговори по отношение на комуникацията.

Важно е, че наличието на NAPT устройство по протежение на пътя се намира в началото на процеса на преговори IKE. Това се прави на два етапа:

Веднага след като използването на IPSec NAT Traversal съгласи, IKE трафик ще се премести в новия брой на UDP порт, IKE с глава ще се промени на плаващ горен и IKE връстници зад устройството за NAPT ще започне да изпраща NAT-Keepalive пакети. Тъй като тези три промени са много важни, нека да ги разгледа по-подробно.

Основната цел на IPSec NAT Traversal е да има общ NAPT прозрачен разтвор. Общоизвестно е, че на пазара има някои IPSec-наясно NAPT устройства. Те използват някои специфични за всяка компилатори продавача (хакове), за да се позволи преминаването на IPSec трафик чрез собствените си устройства. Въпреки това, по този начин, те се предотврати редовен IKE трафикът по UDP порт 500. Поради факта, че общото решение не може да открие всякаква възможност за разработчиците на NAPT устройства IPSec NAT Traversal протокол решават да се преместят само трафика IKE на UDP порт 500 за да се избегне никакви проблеми с IPSec-наясно NAPT устройства. Ето защо, веднага след като използването на IPSec NAT-T се съгласи на нов UDP порт 4500. Забележка трябва да се използва, че всяко изпълнение, който поддържа NAT Traversal, също трябва да поддържа IKE преговори, които се движат по UDP порт 4500, вместо на UDP порт 500 по подразбиране. Разбира се, ако преговорите започва незабавно на UDP порт 4500, пристанището няма промяна в общия случай не е необходимо.

В допълнение към промяната порта на UDP, данни IKE трябва да бъдат допълнени с нестопанска ESP маркер, който позволява на получателя да се направи разграничение между съобщението IKE и UDP-капсулирани ESP пакета. Не-ESP маркер е нищо друго освен нула октет 4 (x'00 "). Тя е умело съчетан с областта на UDP SPI капсулирани ESP пакет. Този нов формат, наречен плаващ IKE глава (носеше IKE Header) и е показано на фигурата по-долу.

Единствената цел на изпращане на NAT-оправдателни пакети е да се запази UDP съответствия в NAPT устройство работи по време на свързване между IPSec партньорска ите. NAT - поддържа пакета е стандартен UDP съобщение, което използва същата UDP порт 4500, трафикът IKE, съдържа един октет (0xFF) като полезния товар. По подразбиране, NAT-KeepAlive интервал е настроена на 20 секунди бездействие във връзка с това. Моля, имайте предвид, че не NAT-KeepAlive пакети се изпращат на UDP порт 500.

2.3. UDP капсулиране на IPSec пакети

IETF RFC 3948 «UDP капсулиране на IPsec пакети» (UDP капсулиране на IPsec пакети) определя методи за капсулиране и декапсулация на пакети IP ESP (капсулиране сигурност полезен товар-капсулираните данни за сигурност) в рамките на пакета UDP да преминат NAPT. UDP капсулиране се използва всеки път, когато договаря посредством протокола Internet Key Exchange (IKE).

Най-важното тук е въвеждането на стандартна UDP глава между IP и ESP глава, както е показано на горната фигура. UDP порт номера трябва да бъдат същите като тези, използвани за IKE пакети след IPSec NAT Traversal е в съгласие (UDP порт 4500). Това означава, че Айк и UDP капсулирани ESP пакети използват едни и същи UDP портове. Както вече споменахме, за да се направи разграничение между пакета IKE и UDP-капсулирани ESP пакет, получателят трябва незабавно да се покажат първите 4 байта след UDP хедъра да демултиплексиране трафик. Ако всички те са равни на нула, а след това е IKE пакет (Non-ESP Маркер), в противен случай това е UDP капсулирани ESP пакет. Следователно, стойността на SPI (Сигурност Параметри индекс) полета в заглавната ESP трябва винаги да бъде различна от нула.

Заслужава да се отбележи, че UDP шах в UDP-капсулирани ESP хедър, плаващ с глава и IKE NAT-подкрепа удар с глава на която се предоставя като нулева стойност. Въпреки това, получателят не трябва да зависи от UDP шах, която е равна на нула. Това идва да покаже, че получаващата IPSec партньорската не трябва да се провери UDP стойност на контролна сума за тези пакети.

Тъй като една от основните приложения на IPSec VPN е сценарий на клиент-шлюз (клиент-портал), разтвор на NAT Traversal ясно подкрепя L2TP върху IPSec транспорт и режим на тунел IPSec реализации. Сега нека накратко помисли пълен пакет структура за два случая:

Забележка: Обсъждане на всички "за" и "против" двете реализации е извън обхвата на тази статия. Все пак, имайте предвид, че макар и тунелен режим пакет структурата на IPSec изглежда просто, че не е необходимо в най-доброто решение за клиента шлюза (клиент-шлюз) VPN сценарий.

3. Конфигурация на ISA

Сега, когато се разбере как IPSec NAT прекосявам, поне по отношение на комуникацията, не трябва да бъде трудно да се преведат тези знания в необходимите определения протокол, протокол правило, и върховенството на "saytkontent" за ISA Server.

конфигурационните стъпки на ISA сървър:

  • Създаване на определение протокол за протокола IPSec IKE:
  • Създаване на определение протокол за протокола IPSec NAT-T:
  • Създаване на правило за протокол, позволяващ на протоколите IPSec IKE и IPSec NAT-T:

    Разбира се, на върховенството на "saytkontent" трябва да съществува, което позволява достъп до дестинация VPN шлюз. В допълнение, може да се наложи да деактивирате IP Filtering Фрагмент от сървъра на ISA (IP Packet Filter имоти Имоти в IP пакети филтър), особено ако сертификатите се използват в процеса на удостоверяване на VPN.

    4. Конфигуриране на ISA Клиенти

    За да разберете как хоста на клиента, трябва първо да се разбере нивото, на което трябва да се конфигурира протокол стека на TCP / IP работи на различни видове ISA клиента и IPSec клиент.

    Следващата фигура показва логически оглед на TCP / IP протоколен стек:

    Забележка: Имайте предвид, че един-единствен хост може да бъде конфигуриран като SecureNAT, Firewall и уеб прокси клиент без никакви неблагоприятни взаимодействия между настройките за конфигурация на клиента.

    4.1. Уеб прокси клиент

    За разлика от клиента Firewall, уеб прокси клиент не е парче от софтуер, който трябва да инсталирате. Той принадлежи към Web клиентски приложения, които са конфигурирани да използват ISA Server, като сървър уеб прокси. В повечето случаи, това ще бъде CERN-съвместим уеб браузър.

    4.2. Firewall клиент

    Firewall клиент е една много интересна част от софтуера и работи ръка за ръка с услугата Firewall на ISA сървър. На платформи, които поддържат Winsock 2.0, клиентът реализира като доставчик на слойни услуги (LSP). На други платформи, приложението за настройка на клиент преименува оригиналната библиотека Winsock DLL (wsock32.dll) и определя своя собствена wsock32.dll изпълнение. Firewall клиент комуникира с услугата Firewall, с помощта на специален връзка, наречена контрол клиент канал Firewall (защитна стена контрол канал клиент). Необходима е връзка пилотен канал.

    4.3. SecureNAT клиент

    SecureNAT клиент принадлежи към мрежа слой (слой), тъй като това зависи от конфигурацията на шлюза и инфраструктура мрежа маршрутизация.

    4.4. IPSec клиент

    4.5. въпроси за конфигурация

    5. Специфична изпълнение

    В подкрепа на това нестандартно изпълнение на IPSec NAT Traversal, което трябва да знаете, на първо място, как да включите тази функция на клиента VPN и врата, и знам точно на пристанището UDP се използва за UDP капсулиране. Всеки VPN администратор, който познава работата си, за да бъде в състояние да ви даде тази важна информация. В противен случай ще трябва да предприеме някои изследвания и да посетите интернет сайта на VPN на доставчици или се обадете на техническата им поддръжка.

    5.1. контролно-пропускателен пункт

    Ако беше инсталирана CheckPoint 4.1 SP6 или NG1 FP1 или по-висока, тя щеше да работи със следните определения протокол:

    • UDP 500 (изпращане (изпрати) -За (получите)) - за удостоверяване
    • UDP 2746 (изпратете-получите) - за криптиран трафик
    • TCP 264 (изход (Изходящ)) * * по желание - да се актуализира топологията

    5.2. Cisco

    Доколкото ми е известно, NAT-T е активирана по подразбиране в поредица от Cisco VPN концентратор 3000. Въпреки това, Cisco PIX Трябва да включите подкрепа NAT-T изрично помощта на команда «ISAKMP NAT-прекосява [natkeepalive]». Подкрепа (за проверка на връзката) са настроени по подразбиране до 20 секунди (диапазона от 10 до 3600 секунди). Също така, уверете се, че средства Прозрачен Пробиване на тунели (прозрачен тунелиране) е активиран на главината Cisco VPN концентратор.

    Някои хора са се опитвали да използват собствен вариант на Cisco за капсулиране на трафика IPSec по един TCP връзка чрез сървъра ISA. Този механизъм е въведен във версия 3.5 VPN клиент. Въпреки това, Cisco документация ви предупреждава, че тя не се поддържа чрез всеки прокси сървър. Тъй като ISA сървър изтрива оригиналния заглавието и създава нови, следователно действа като прокси сървър, TCP капсулиране няма да работи през ISA Server. Това не е проблем на сървъра ISA, това е следствие от факта, че Cisco VPN концентратора не се занимава с координацията MSS, подходящи спецификации RFC.

    5.3. Microsoft

    5.4. NetScreen

    Доколкото ми е известно, NetScreen реализира NAT Traversal тъй ScreenOS 3.0.0 или по-късно и NetScreen Remote версия 6.0 или по-късно, обаче, изглежда, че те подкрепят - е първата версия на проекта. NetScreen Remote клиент автоматично установява дали Peer VPN (NetScreen единица) NAT прекосявам и UDP капсулирани ESP пакети, изпратени от самия оригинал на IKE UDP порт 500, вместо на новия UDP порт 4500.

    За да се даде възможност на NAT-T за клиента, просто включете NAT-T опция на екрана на врата при конфигуриране на потребителя (User) на кутията NetScreen. Също така, уверете се, че при инсталиране на Фаза 1 Предложение (Фаза 1 предложение) за NAT-T, UDP опция контролна (UDP контролна) е забранено.

    5.5. Nortel Contivity

    Можете да премине клиентски софтуер Nortel Екстранет достъп чрез ISA Server, ако преминаването Nortel Contivity (превключвател) работи с един от най-новата версия на фърмуера 04_05.024 или по-възрастни и използвате най-новата версия клиентски софтуер 4.65 или по-късно. Ето какво трябва да направите, за ключа Contivity (Switch):

    • От лявата страна на страницата с конфигурацията, кликнете върху «услуги», а след това «IPSEC». Към средата на страницата е настройка «NAT Traversal». Уверете се, че сте го включили и да го настроите да UDP порт 4500 (силно препоръчително).
    • След стъпката по-горе е направено, отидете на «Профили», след това «Групи». Под определена група, в която искате да има NAT Traversal активирана, кликнете върху «Редактиране». Под раздел «IPSEC» кликнете върху «Configure». В долната част на страницата, уверете се, че «Автоматично определяне на NAT» избран и запази «NAT Keepalive» от стойността на 18 секунди.

    Ако администраторът е настроил VPN NAT Traversal порт за нещо различно от пристанището UDP 4500 (т.е. UDP порт 10001), трябва да се вземат, съответно, IPSec NAT-T определение протокол или създайте нов и го добавете към правило протокол пропускателен на IPSec.

    5.6. Sonicwall

    SonicWALL фърмуер (фърмуер) 6.3, VPN клиент версия 8.0 и Global VPN Client версия 1.0 поддържа IPSec NAT Traversal. Тъй като изглежда, че последните версии, предполагам, че вече са започнали UDP порт 4500 за UDP капсулиране на ESP пакети и че изпълнението поддържа автоматично договаряне NAPT устройство по пътя (по пътя).

    6. Заключение