Cum de a trece traficul IPSec prin serverul isa

2. IPSec NAT

Un fapt bine-cunoscut faptul că protocolul IPSec nu a fost proiectat ținând cont de existența NAPT. Folosind protocolul IPSec nu este de obicei o problemă în poarta de acces la gateway (poarta de acces la gateway) scenariu VPN, deoarece gateway-urile VPN instalate pe marginea rețelei, să se asocieze. Cu toate acestea, una dintre cele foarte populare aplicații VPN-uri este de a oferi acces de la distanță la Intranet corporative. Astăzi NAPT-uri pe scară largă desfășurate în gateway-uri la domiciliu, precum și în alte locații susceptibile de a fi utilizate de către Telecommuters. Rezultatul este că incompatibilităților IPSec-NAPT au devenit un obstacol major pentru implementarea IPSec în client-Gateway (client-to-Gateway) scenarii VPN.

Descrierea detaliilor tehnice exacte cu privire la incompatibilități cunoscute între NAPT și protocoalele IPSec este dincolo de domeniul de aplicare al acestui articol. Dacă sunteți interesat de acest nivel de detaliu, ar trebui să citiți IETF RFC Informational 3715 «IPSec-NAPT de compatibilitate Cerințe» (cerințe IPsec-NAT compatibilitate), scrisă de Bernard Adobe (Bernard Aboba) și William Dixon (William Dixon) de la Microsoft.

Este păcat că cele două articole excelente (de la Microsoft TechNet Webcast) «IPsec NAT-T: În sfârșit, în armonie? (Nivel 400) »(IPsec NAT-T :? În cele din urmă, în Harmony (Nivel 400)) și«IPsec Demistificarea (Nivel 400)»(Demistificarea IPsec (Nivel 400)) furnizate de Steve Riley (site-ul Steve Riley), nu mai este Microsoft Webcast disponibile pe site-ul. Cu toate acestea, pe site-ul lui Steve Riley (site-ul Steve Riley) Tu trebuie să fie capabil să găsească un excelent powerpoint-prezentare «IPsec și NAT: În cele din urmă în armonie» (site-ul Steve Riley ar trebui să fie în măsură să găsească prezentarea excelentă powerpoint IPsec și NAT: În cele din urmă în armonie.

Pentru a permite desfășurarea în IPSec client-Gateway (client-to-Gateway) scenariu VPN, IETF în cele din urmă a lucrat dintr-o soluție numită NAT. Deoarece unul dintre principalele aplicații ale IPSec este un acces de la distanță la un rețele Intranet corporative, soluție NAT-T trebuie să mențină o trecere prin dispozitivul NAPT sau modul tunel IPSec sau L2TP prin modul de transport IPSec. Aceasta include suport pentru trecerea (traversal), mai mult de un dispozitiv NAPT între client la distanță și gateway VPN. Elementele cheie ale soluției NAT:

  • Folosind protocolul IPSec AH nu este acceptat.
  • Potrivirea NAT-și IKE.
  • UDP încapsulare (formarea unui pachet) pachete IPSec.

2.1. Folosind protocolul IPSec AH nu este acceptat

Notă: Câmpurile variabile din antetul IP sunt tip de serviciu (tip de serviciu) (TOS), Fragment Offset (fragment de offset), steaguri (steaguri), Time to Live (timpul de viață) (TTL), IP antet de control (control IP antet).

2.2. NAT în armonizarea IKE

IETF RFC 3947, „Armonizarea NAT-Traversal în IKE» (Negocierea NAT-Traversal în IKE) descrie modul de a găsi sprijin pentru trecerea prin NAT în gazde IPSec, cum de a detecta una sau mai multe dispozitive de NAPT de-a lungul drum (de-a lungul căii), și cum să reconcilieze utilizarea UDP încapsularea pachetelor IPSec prin blocuri NAPT. Acest lucru se face prin definirea unor modificări și extensii ale protocolului IKE (schimbul de chei Internet Key Exchange Internet). Pentru a înțelege mai bine ce se întâmplă în spatele scenei, să ne treacă prin procesul de negociere în ceea ce privește comunicarea.

Este important ca prezența unui dispozitiv de NAPT de-a lungul modul în care se găsește la începutul procesului de negociere IKE. Acest lucru se face în două etape:

De îndată ce utilizarea IPSec NAT a fost de acord, traficul IKE se va muta la noul număr de port UDP, antet IKE va fi schimbat la un antet plutitoare și IKE la egal la egal în spatele dispozitivului NAPT va începe să trimită pachete NAT-KeepAlive. Din moment ce aceste trei schimbări sunt foarte importante, să le examinăm mai în detaliu.

Scopul principal al IPSec NAT este de a avea o soluție generică transparentă NAPT. Este cunoscut faptul că în piață există unele dispozitive NAPT IPSec-conștient. Ei folosesc unele specifice fiecărui compilatoare de furnizor (hackuri), pentru a permite trecerea traficului IPSec prin propriile dispozitive. Cu toate acestea, procedând astfel, acestea împiedică traficul obișnuit IKE pe portul UDP 500. Datorită faptului că soluția generală nu poate detecta orice posibilitate a unui dispozitiv de NAPT dezvoltatori protocolul IPSec NAT a decis să se mute doar traficul IKE pe portul UDP 500, pentru a evita orice probleme cu dispozitive NAPT IPSec-conștient. Prin urmare, de îndată ce utilizarea IPSec NAT-T a fost de acord ar trebui să fie utilizat un nou port UDP 4500. Notă, că orice punere în aplicare care acceptă trecerea prin NAT, trebuie să sprijine, de asemenea, IKE de negociere care rulează pe portul UDP 4500 în loc de portul UDP 500 implicit. Desigur, în cazul în care negocierea începe imediat pe portul UDP 4500, portul nici o schimbare, în general, nu este necesar.

În plus față de schimbarea portul UDP, datele IKE ar trebui să fie completate de marcaj non-ESP, care permite destinatarului să facă o distincție între mesajul IKE și UDP-încapsulat pachet ESP. Nu-ESP markerul nu este altceva decât nul octetul 4 (X'00 „). Este perfect combinat cu câmpul SPI al UDP încapsulat de pachete ESP. Acest nou format numit plutitoare IKE header (pluteau IKE Header) și este ilustrată în figura de mai jos.

Unicul scop de a trimite pachete NAT-de sprijin este de a menține mapări UDP în dispozitivul NAPT operabil pe timp de conectare între IPSec peer-uri. NAT - sprijină pachetul este un mesaj UDP standard care utilizează același port UDP 4500, traficul IKE, conține un singur octet (0xFF) ca sarcina utilă. În mod implicit, intervalul de NAT-Keepalive este setat la 20 de secunde de inactivitate în acest sens. Vă rugăm să rețineți că nu-pachete NAT Keepalive sunt trimise pe portul UDP 500.

2.3. încapsularea UDP de pachete IPSec

IETF RFC 3948 «UDP încapsularea pachetelor IPsec» (UDP încapsularea IPsec Pachete) definește metode pentru încapsulare și decapsulation pachetelor IP ESP (încapsulare Security Payload-încapsulată Security Payload) in interiorul pachetului UDP pentru a trece NAPT. încapsularea UDP este folosit ori de câte ori negociată folosind protocolul Internet Key Exchange (IKE).

Cel mai important punct aici este introducerea unui antet UDP standard, între IP și antetul ESP, așa cum este indicat în figura de mai sus. Numerele de port UDP trebuie să fie aceleași cu cele utilizate pentru pachetele IKE după IPSec NAT este de acord (portul UDP 4500). Acest lucru înseamnă că Ike și UDP încapsulat pachetele ESP utilizează aceleași numere de port UDP. După cum sa menționat deja, să se facă distincția între pachetul IKE și UDP-încapsulată pachet ESP, destinatarul trebuie să verifice imediat primele 4 octeti după antetul UDP la demultiplexarea de trafic. Dacă acestea sunt egale cu zero, atunci este un pachet IKE (Non-ESP Marker), în caz contrar acesta este un pachet UDP încapsulat ESP. Prin urmare, valoarea SPI (câmpuri de securitate Parametrii Index) în antetul ESP trebuie să fie întotdeauna non-zero.

Este demn de menționat faptul că suma de control UDP în antetul ESP UDP-încapsulată, un antet plutitoare și antet IKE NAT-de sprijin care urmează să fie transmisă ca valoare zero. Cu toate acestea, beneficiarul nu trebuie să depindă de control UDP, care este zero. Se pare să indice faptul că primirea IPSec la egal la egal nu ar trebui să verifice valoarea sumei de control UDP pentru aceste pachete.

Deoarece una dintre aplicațiile principale ale IPSec este un scenariu VPN client-to-Gateway (client-to-Gateway), soluție NAT sprijină în mod clar L2TP prin modul de transport IPSec și modul tunel IPSec implementări. Acum, să ne ia în considerare pe scurt o structură completă, pachet pentru cele două cazuri:

Notă: Discutarea tuturor „pentru“ și „contra“, cele două implementări este dincolo de domeniul de aplicare al acestui articol. Cu toate acestea, ține cont de faptul că, deși IPSec structura de pachete de modul tunel pare simplu, nu este nevoie de cea mai bună soluție pentru client-Gateway (client-to-Gateway) scenariu VPN.

3. Configurarea ISA Server

Acum, că am înțeles modul în care IPSec NAT traversal, cel puțin în ceea ce privește comunicarea, ar trebui să nu fie dificil de a traduce aceste cunoștințe în definițiile de protocol necesare, de regulă de protocol, și statul de „saytkontent“ pentru ISA Server.

Pașii de configurare pe serverul ISA:

  • Crearea unei definiții de protocol pentru protocolul IPSec IKE:
  • Crearea unei definiții de protocol pentru protocolul IPSec NAT-T:
  • Crearea unei reguli de protocol care să permită protocoalele IPSec IKE și IPSec NAT-T:

    Desigur, regula de „saytkontent“ ar trebui să fie în loc să permită accesul la destinație VPN gateway-ului. În plus, poate fi necesar pentru a dezactiva IP Fragment Filtrare pe serverul ISA (pachete IP Filter proprietăți proprietăți IP filtru de pachete), în special în cazul în care certificatele sunt utilizate în procesul de autentificare VPN.

    4. Clienți Configurarea ISA

    Pentru a înțelege modul în care gazda de client, trebuie să înțelegem mai întâi nivelul la care trebuie să fie configurat un protocol stiva TCP / IP care rulează diferite tipuri de client ISA și client IPSec.

    Următoarea figură prezintă o vedere logică a stiva protocolului TCP / IP:

    Notă: Rețineți că o singură gazdă poate fi configurat ca un SecureNAT, Firewall și Web client proxy, fără nici o interacțiune nefavorabilă între setările de configurare client.

    4.1. client Web Proxy

    Spre deosebire de clientul paravan de protecție, clientul Web Proxy nu este o bucată de software pe care ar trebui să instalați. Ea face parte din aplicațiile Web client care sunt configurate pentru a utiliza ISA Server ca un server Web Proxy. În cele mai multe cazuri, acesta va fi un CERN compatibil cu browser-ul Web.

    4.2. clientul paravan de protecție

    clientul paravan de protecție este o piesă foarte interesantă de software și lucrează mână în mână cu serviciul Firewall pe serverul ISA. Pe platformele care acceptă Winsock 2.0, clientul implementat ca un furnizor de servicii stratificat (LSP). Pe alte platforme, aplicația de configurare client redenumește biblioteca originală Winsock DLL (Wsock32.dll) și stabilește propria Wsock32.dll de punere în aplicare. clientul paravan de protecție comunică cu serviciul Firewall, utilizând o conexiune dedicat numit canalul de control client paravan de protecție (firewall-canal de control al clientului). Este nevoie de conexiune de canal pilot.

    4.3. client SecureNAT

    client SecureNAT aparține stratului de rețea (strat), deoarece aceasta depinde de configurația gateway-ului și o infrastructură de rețea de rutare.

    4.4. client IPSec

    4.5. problemele de configurare

    5. punerea în aplicare specifică

    Pentru a sprijini punerea în aplicare a acestor non-standard a IPSec NAT, trebuie să știți, în primul rând, cum să activați această funcție pe client VPN și poarta de acces, și știu exact portul UDP utilizat pentru UDP încapsulare. Orice administrator de rețea VPN care știe treaba lui, să fie în măsură să vă dau aceste informații importante. În caz contrar, va trebui să efectueze unele cercetări și să vizitați site-urile VPN ale furnizorilor sau apelați suportul tehnic.

    5.1. Punct de control

    Dacă ați fi instalat CheckPoint 4.1 SP6 sau NG1 PF1 sau mai mare, ar fi lucrat cu următoarele definiții de protocol:

    • UDP 500 (trimite (trimite) -sa (primi)) - pentru a te autentifica
    • UDP 2746 (trimite-primi) - pentru traficul criptat
    • TCP 264 (de ieșire (ieșire)) * * opțional - pentru a actualiza topologia

    5.2. Cisco

    Din câte știu, NAT-T este activată implicit într-o serie de Cisco VPN Concentrator 3000. Cu toate acestea, Cisco PIX trebuie să includă suport NAT-T folosind în mod explicit comanda «isakmp-nat traversal [natkeepalive]». Suport (keep-alive) set implicit la 20 de secunde (variază de la 10 la 3600 de secunde). De asemenea, asigurați-vă că tunelare transparent mijloc (tunelare transparent) este activat pe hub-ul Cisco VPN Concentrator.

    Unii oameni au încercat să folosească opțiunea proprie Cisco pentru a încapsula traficul IPSec printr-o singură conexiune TCP prin serverul ISA. Această facilitate a fost introdusă în versiunea 3.5 client VPN. Cu toate acestea, documentația Cisco vă avertizează că nu este susținută prin orice server proxy. Deoarece serverul ISA șterge antetul original și creează noi, prin urmare, acționează ca un server proxy, TCP încapsulare nu va funcționa prin ISA Server. Aceasta nu este o problemă ISA server, aceasta este o consecință a faptului că Cisco VPN Concentrator nu se ocupă de coordonarea MSS, specificațiile RFC corespunzătoare.

    5.3. Microsoft

    5.4. NetScreen

    Din câte știu eu, NetScreen implementat prin NAT, deoarece ScreenOS 3.0.0 sau mai târziu și NetScreen Remote versiunea 6.0 sau mai târziu, însă, se pare că acestea sprijină - este prima versiune a proiectului. NetScreen client la distanță detectează automat dacă Peer VPN (unitate NetScreen) NAT traversal, iar UDP încapsulat pachetele ESP trimise pe original portul IKE UDP 500 în loc de noul port UDP 4500.

    Pentru a activa NAT-T pentru client, pur și simplu activați opțiunea NAT-T de pe ecranul de gateway la configurarea (Utilizator) pe caseta NetScreen. De asemenea, asigurați-vă că, atunci când instalarea Faza 1 propunere (Faza 1 propunere) pentru NAT-T, opțiunea de control UDP (control UDP) este dezactivat.

    5.5. Nortel Contivity

    Puteți trece software-ul client Nortel Extranet Access prin ISA Server, în cazul în care comutatorul Nortel Contivity (comutator) este de lucru cu unul dintre cele mai noi versiuni de firmware 04_05.024 sau mai în vârstă și utilizați cea mai recentă versiune de software client 4,65 sau mai târziu. Iată ce trebuie să faci pe comutator Contivity (comutator):

    • Pe partea stângă a paginii de configurare, faceți clic pe «Servicii», apoi «IPSEC». Spre mijlocul paginii este înființarea «NAT». Verificați dacă l-ați pornit și setați-l la portul UDP 4500 (recomandat).
    • După etapa de mai sus se face, du-te la «Profiluri», apoi «Grupuri». În cadrul unui grup definit, în care doriți să aveți un NAT activat, faceți clic pe «Editare». Sub secțiunea «IPSEC» click pe «Configurare». În partea de jos a paginii, asigurați-vă că «Auto-Detect NAT» selectat și să păstrați «NAT Keepalive» cu privire la valoarea de 18 secunde.

    În cazul în care administratorul a configurat portul VPN NAT la altceva decât portul UDP 4500 (de exemplu, UDP portul 10001), trebuie să luați, respectiv, IPSec definiție de protocol NAT-T sau de a crea unul nou și adăugați-l la IPSec regula protocolul passthrough.

    5.6. SonicWALL

    SonicWALL firmware-ului (firmware) 6.3, VPN client versiunea 8.0 și Global VPN Client versiunea 1.0 suportă IPSec NAT. Din moment ce se pare a fi de presă recente, presupun că acestea sunt deja folosind portul UDP 4500 pentru încapsularea UDP de pachete ESP și că implementarea suportă dispozitiv NAPT Autonegotiation de-a lungul drum (de-a lungul căii).

    6. Concluzie