Network Address Translation (NAT)

Network Address Translation (NAT) се използва често в среди, притежаващи лично пространство с IP адреси, за разлика от собственост на глобално-уникален IP адрес. Блокът с глобално уникални IP адреси обикновено се получава от доставчика на мрежовата услуга, въпреки че по-големите корпорации може да се обърнат към Интернет доставчика директно за адресно пространство. NAT ще преведе нерегистрираните IP адреси в законни IP адреси с възможност за маршрутизиране във външната публична мрежа.

Internet Assigned Numbers Authority (IANA) е резервирала следните три блокa oт IP адресни пространства за частни мрежи в следните класове:
• A: мрежов адрес 10.0.0.0 - 1 мрежа. Диапазон: 10.0.0.0 - 10.255.255.255
• B: мрежови адреси 172.16.0.0 до 172.31.0.0 - 16 мрежи. Диапазон: 172.16.0.0 - 172.31.255.255
• C: мрежови адреси 192.168.0.0 до 192.168.255.0 - 256 мрежи. Диапазон: 192.168.0.0 до 192.168.255.255
Ако някоя корпорация реши да използва частно адресиране, трябва да използва тези блокове от адреси.
В някои мрежи, броят на използваните нерегистрирани IP адреси може да надвиши броя на глобалните уникални адреси, достъпни за превод. За да се реши този проблем, беше създадено Port Address Translation (PAT). Когато се използва NAT/PAT, TCP или UDP портовете на източника, използвани при установяване на връзката, се запазват уникални и се поставят в таблица заедно с преведения ГР адрес на източника. След това връщаният трафик се сравнява с NAT/PAT таблицата и IP адреса и номерата на TCP или UDP портовете на получателя се променят, за да отговарят на запазените в таблицата. Фигура 3-4 илюстрира работата на NAT/PAT.
Използването на NAT/PAT създава редица проблеми за много протоколи. Приложения, които променят номерата на UDP или TCP портовете на изпращача и получателя, може да разрушат PAT съответствията. Също така, приложения, използващи контролен канал, за да обменят информация за съответствия на номера на портове и IP адреси ще се дадат несъответствие при NAT/PAT (например FTP). Освен това, ако зад дадено NAT/PAT устройство се намират много потребители, IP адресите и/или номерата на разположение може да се изчерпят доста бързо.
Използването на NAT води до редица проблеми и при употребата с IPsec. Както обаче беше разяснено в глава 2, съществува разширение NAT Traversa], което е в процес на стандартизация, и което ще създаде работещо решение за много NAT среди. Следните проблеми биват разрешени чрез използването на NAT Traversal:
• Изчисляване на контролна сума за по-горен слой - Когато TCP или UDP контролната сума бъде криптирана с ESP, NAT устройството не можа де я изчисли. NAT Traversal дефинира допълнителни полезни данни в IKE, които изпращат оригиналните IP адреси за правилно изчисляване на контролната сума.
• Мултиплексиране на потоци с IPsec данни - TCP и UDP хедъ-рите не са видими при ESP, и поради това номерата на TCP или UDP портовете не могат да бъдат използвани за мултиплексиране на трафика между различни хостове, използващи адреси от частна мрежа. NAT Traversal капсулира ESP пакета с UDP хедър и NAT има възможност да използва UDP портовете на този хедър, за да мултиплексира потоците с IPsec данни.
• Промяна на номера на IKE UDP порт - Ако някоя IPsec IKE им-плементация очаква номера на UDP порта на източника и дестина-цията да бъдат едновременно 500, когато някое NAT устройство промени номера на UDP порта на източника, IKE трафикът може да бъде изгубен. NAT Traversal дава възможност IKE съобщенията да се получават от порт на източника, различен от 500.
• Използване на IP адреси за идентификация - Ако вграден ГР адрес се използва идентификация на участника, когато NAT промени адреса на източника на изпращащия възел, вграденият адрес няма да съвпада с IP адреса на IKE пакета и ГКЕ договарянето ще пропадне. NAT Traversal изпраща оригиналния IP адрес по време на договарянето в бърз режим от фаза 2 на IKE, който може да бъде използван за потвърждаване на ГР адреса. Обърнете внимание, че тъй като тези полезни данни не се изпращат по време на договарянето в основен режим от IKE фаза 1, потвърждаването на IP адреса не може да се извърши и проверката или изобщо не трябва да се случва, или тя трябва да става посредством друг механизъм, например проверка на името на хоста.

Point-to-Point Tunneling Protocol (РРТР)
РРТР предоставя удостоверени и криптирани комуникации между клиент и шлюз или между два шлюза чрез използването на потребителски тунел в публичното Интернет пространство.
Разработката на РРТР беше започната от Microsoft и след приноса и на други производители се превърна в информационен стандарт от EETF, RFC 2637. За първи път този протокол беше доставен в продукти през 1996 г., две години преди да се появят IPsec и L2TP. Целта на проекта беше простота, поддръжка на множество протоколи и възможност за поддръжка на IP мрежи. РРТР използва TCP връзка (чрез TCP порт номер 1723) за поддръжка на тунел и РРР кадри, капсулирани чрез Generic Routing Encapsulation (GRE) за тунелираните данни. Полезните данни на РРР кадрите могат да бъдат криптирани и/или компресирани. Въпреки че РРР Encryption Control Protocol (ЕСР), дефиниран в RFC 1968, и РРР Compression Control Protocol (ССР), дефиниран в RFC 1962, могат да бъдат използвани заедно с РРТР за извършване на криптиране и компресиране, повечето имплементации използват Microsoft Point-to-Point Encryption (MPPE), дефиниран в RFC 3078, Microsoft Pint-to-Point Compression (MPPC), дефиниран в RFC 2118. Подобни технологии се изполват от фирмите за уеб дизайн услуги и разработчиците на сайтове, при създаване на уеб сайтове, в които се налага да се използва криптирана връзка.
Употребата на РРР предоставя възможност за договаряне на услуги за удостоверяване, криптиране и присвояване на адреси. РРР удостоверяването обаче не предлага удостоверяване, цялост или защита от атаки с повторение за всеки отделен пакет, а механизмът за криптиране не задоволява изисквания за удостоверяване, цялост и защита срещу атаки с повторение и управление на ключове.

ЗАБЕЛЕЖКА
РРР ЕСР въобще не засяга управлението на ключове. МРРЕ обаче предлага генериране и управление на ключ за сесията, който се извлича от MS-CHAP или EAP-TLS акредитации. Спецификацията може намерите в RFC 3079.

Повечето NAT устройства имат възможност да препредават ТСР-бази-ран трафик за поддръжка на РРТР тунел, но РРТР пакетите с данни, използващи GRE хедър, обикновено трябва да използват допълнителни съответствия в NAT устройството - полето Call ГО в GRE хедъра се използва за осигуряване на уникален идентификатор за всеки РРТР тунел и за всеки РРТР клиент.
РРТР не предлага много силно криптиране, защото е базиран на стандарта RSA RC4 и поддържа 40-битово или 128-битово криптиране. Той не е разработен за тунелиране LAN-към-LAN, а някои имплементации са наложили допълнителни ограничения, например предоставяне само на 255 връзки към даден сървър и само по един VPN тунел за всяка клиентска връзка.

• Протокол ARP. Действие на ARP.ARP механизъм за кеширане Address Resolution Protocol (ARP) Протоколът ARP (Address Resolution Protocol), дефиниран в RFC 826, динамично изпълнява последното преобразуване на адреси. Първоначалният проект на протокола ARP поддържаше преобразуването на логически адреси от...
• Хардуерни компоненти, услуги, протоколи Дънна платка Дънна платка е основната платка на компютъра, която се поставя закрепена за един от страничните капаци на компютърната кутия. Тя представлява лист, направен от стъклотекстолит, по който се...
• WAN Мрежи, WAN Технологии автор: Даниел Николаев Колев Мрежата е група от компютри, свързани по такъв начин, че да могат да споделят информация и оборудване. Мрежата може да има всякакъв размер. Може да бъде...
• Свързване на компютърни мрежи Свързване на локални компютърни мрежи. Междумрежови комуникации. Основни принципи. Локалните компютърни мрежи (ЛКМ) обединяват голям брой работни станции (PC) и предоставят на потребителите определени услуги. Все по-голямо значение придобива обаче...

Web design and SEO topics: IP, Интернет, комуникации, мрежи

Web site categories: Интернет
« Технологии за LED подсветка
Web дизайн и грешките в HTML кода »




Reader's Comments

1. Layer 2 Tunneling Protocol (L2TP) | Интернет, компютри, Web, Високи технологии | 21 Apr 2011 5:19 am

   [...] структу­ра за адресиране на Dynamic Host Configuration Protocol (DHCP) и NAT (Network Address Translation), както и legacy удостоверяване на [...]





Leave a Comment

Name (required)

Mail (will not be published) (required)

Website