Check Point VSX VPN: linkvalg eller peer-uoverensstemmelse?

To forskellige ændringer giver det samme symptom, når en Check Point-tunnel mellem to lokaliteter holder op med at komme op: peer'en ser en anden ekstern adresse, eller den afviser den IKE-identitet, den nu modtager. På en optagelse fra den ene side ser de ens ud. At afgøre, hvilken af dem du har, kræver tre kontroller, og ingen af dem er linkvalgs-panelet.

Rammer du rækkefølgen forkert, justerer du kildevalget for at rette en identitetsuoverensstemmelse. Det er sådan, den samme tunnel bliver rettet to gange og går i stykker igen efter den næste ruteændring.

Tre betingelser, der skiller de to tilfælde

Betingelse et: passer peer'ens konfigurerede endepunkt til den adresse, der faktisk ankommer? Hvis pakker når den fjerne gateway fra en adresse, som den ikke forbinder med dit peer-objekt, mislykkes forhandlingen, før nogen identitet udveksles. Betingelse to: passer IKE-identiteten i forslaget til den værdi, peer'en forventer? Det er autentificering, ikke transport. Betingelse tre: er den indstilling, du vil ændre, understøttet til dette virtuelle system på denne version? Ingen synlig indstilling besvarer disse spørgsmål.

Hvis betingelse et fejler, har du et rute- eller oversættelsesproblem. Hvis betingelse to fejler, har du et peer-kontraktproblem. Hvis betingelse tre er ukendt, så stop med at konfigurere.

Byg registreringen af den eksterne peer først

Skriv det virtuelle system, softwareversionen og det installerede opdateringsniveau ned, før du rører noget. Registrér derefter de eksterne interfaces, ruten mod den fjerne peer, de forventede kildeadresser før og efter NAT samt den fjerne peers konfigurerede endepunkt.

Hold de indre beskyttede præfikser i en særskilt del af den registrering. At ændre en ekstern kilde og at ændre en beskyttet LAN-adresse er to forskellige handlinger, som tilfældigvis ligger i samme politik.

Tilføj retning til hver optagelse, du beholder. En lokalt initieret forhandling og et svar til den fjerne peer kan vælge forskelligt, så en optagelse uden mærkat er svagt bevis. Mærk filen med det virtuelle system og den part, der startede.

Læs, hvad linkvalg egentlig adskiller

Check Points vejledning til linkvalg i R81.20 adskiller tre ting, som folk smelter sammen til én: hvordan den fjerne peer opløser en gateway-adresse, hvilken rute der bærer den udgående trafik, og hvilken kilde-IP der bruges. Hver især besvarer de et forskelligt spørgsmål. Ingen af dem ændrer den identitet, peer'en autentificerer.

Den adskillelse forklarer, hvorfor en ruteændring kan ændre den synlige eksterne adresse uden at røre IKE-identiteten, og hvorfor en identitetsændring kan brække en tunnel, hvis routing er perfekt.

RFC 7296 trækker samme grænse for IKE selv: identifikations-nyttelasten er ikke transportadressen. Leverandører implementerer den opdeling, de omdefinerer den ikke.

Beslut ud fra bevis, ikke ud fra indstillingspanelet

Hvis peer'en rapporterer en ukendt eller ikke-matchende identitet, så ret peer-objektet eller identitetskonfigurationen, ikke kildevalget. Hvis peer'en intet rapporterer, og din optagelse viser pakker, der forlader en uventet adresse, så ret routing eller oversættelse først. Hvis begge ser rigtige ud, og tunnelen stadig fejler, så optag på den fjerne side og sammenlign, hvad den modtog. Kun når adresse og identitet stemmer, og stien stadig er forkert, bliver en linkvalgsindstilling kandidaten.

Før du konfigurerer den indstilling på VSX, så skaf vejledning om understøttede funktioner for den relevante version eller en udtrykkelig erklæring fra leverandøren for det virtuelle systems kontekst. En ældre rapport om, at en funktion ikke var tilgængelig, er historie, ikke et aktuelt forbud, og et indstillingspanel er ikke en support-erklæring.

Afstem begge ender og gem registreringen

Når du har et understøttet design, så gennemgå ekstern tilgængelighed, peer-endepunktets konfiguration og identitetsaftalen sammen som én kontrakt. Planlæg derefter accept for tre tilfælde: den første forbindelse, en forbindelse startet af den fjerne side, og den fejl, du forventer, når stien bryder sammen.

Gem de observerede eksterne adresser ved siden af den aktive virtuelle systems kontekst. Så sammenligner den næste ruteændring med en dokumenteret kontrakt i stedet for nogens erindring om standarden.