Două modificări diferite produc același simptom atunci când un tunel site-to-site Check Point nu mai urcă: partenerul vede o altă adresă externă sau respinge identitatea IKE pe care o primește acum. Pe o captură luată dintr-o singură parte, ambele arată la fel. Pentru a decide care dintre cele două este cazul, sunt necesare trei verificări, iar niciuna dintre ele nu este panoul de selecție a legăturii.

Dacă greșiți ordinea, reglați selecția sursei pentru a remedia o nepotrivire de identitate. Așa se repară același tunel de două ori și se strică din nou după următoarea schimbare de rută.

Trei condiții care separă cele două cazuri

Prima condiție: punctul final configurat al partenerului corespunde adresei care sosește efectiv? Dacă pachetele ajung la gateway-ul îndepărtat de la o adresă pe care acesta nu o asociază cu obiectul dvs. de partener, negocierea eșuează înainte de a se schimba orice identitate. A doua condiție: identitatea IKE din propunere corespunde valorii așteptate de partener? Aceasta este autentificare, nu transport. A treia condiție: opțiunea pe care doriți să o schimbați este acceptată pentru acest sistem virtual pe această versiune? Nicio setare vizibilă nu răspunde la aceste întrebări.

Dacă prima condiție eșuează, aveți o problemă de rutare sau de traducere. Dacă a doua eșuează, aveți o problemă de contract cu partenerul. Dacă a treia este necunoscută, opriți configurarea.

Construiți mai întâi evidența partenerului extern

Notați sistemul virtual, versiunea software și nivelul de actualizare instalat înainte de a atinge ceva. Apoi înregistrați interfețele externe, ruta către partenerul îndepărtat, adresele sursă așteptate înainte și după NAT și punctul final configurat al partenerului îndepărtat.

Păstrați prefixele protejate interne într-o parte separată a acelei evidențe. Schimbarea unei surse externe și schimbarea unei adrese LAN protejate sunt două operațiuni diferite care se întâmplă să locuiască în aceeași politică.

Adăugați direcția la fiecare captură pe care o păstrați. O negociere inițiată local și un răspuns către partenerul îndepărtat pot selecta diferit, așa că o captură fără etichetă este o dovadă slabă. Etichetați fișierul cu sistemul virtual și cu inițiatorul.

Citiți ce separă de fapt selecția legăturii

Ghidul Check Point pentru selecția legăturii în R81.20 separă trei lucruri pe care oamenii le contopesc într-unul: cum rezolvă partenerul îndepărtat o adresă de gateway, ce rută transportă traficul de ieșire și ce adresă IP sursă este folosită. Fiecare răspunde la o altă întrebare. Niciuna nu schimbă identitatea pe care o autentifică partenerul.

Această separare explică de ce o schimbare de rută poate modifica adresa externă vizibilă fără a atinge identitatea IKE și de ce o schimbare de identitate poate rupe un tunel a cărui rutare este perfectă.

RFC 7296 trasează aceeași linie pentru IKE însuși: încărcătura de identificare nu este adresa de transport. Producătorii implementează această separare, nu o redefinesc.

Decideți pe baza dovezilor, nu a panoului de setări

Dacă partenerul raportează o identitate necunoscută sau nepotrivită, corectați obiectul de partener sau configurația identității, nu selecția sursei. Dacă partenerul nu raportează nimic, iar captura dvs. arată pachete care pleacă de la o adresă neașteptată, corectați mai întâi rutarea sau traducerea. Dacă ambele par corecte și tunelul tot eșuează, capturați pe partea îndepărtată și comparați ce a primit. Numai când adresa și identitatea concordă, iar calea este încă greșită, o opțiune de selecție a legăturii devine candidată.

Înainte de a configura acea opțiune pe VSX, obțineți îndrumările privind funcțiile acceptate pentru versiunea corespunzătoare sau o declarație explicită a producătorului pentru contextul sistemului virtual. Un raport mai vechi că o funcție nu era disponibilă este istorie, nu o interdicție actuală, iar un panou de setări nu este o declarație de suport.

Împăcați ambele capete și păstrați evidența

Odată ce aveți un proiect acceptat, revizuiți împreună accesibilitatea externă, configurația punctului final al partenerului și acordul privind identitatea, ca un singur contract. Apoi planificați acceptarea pentru trei cazuri: conexiunea inițială, conexiunea inițiată de partea îndepărtată și defecțiunea pe care o așteptați când calea se rupe.

Salvați adresele externe observate lângă contextul sistemului virtual activ. Următoarea schimbare de rută se va compara astfel cu un contract documentat, nu cu memoria cuiva despre valoarea implicită.

Articole similare