Check Point VSX VPN: linkselectie of een peer-mismatch?

Twee verschillende wijzigingen geven hetzelfde symptoom wanneer een Check Point-tunnel tussen twee locaties niet meer opkomt: de peer ziet een ander extern adres, of hij weigert de IKE-identiteit die hij nu ontvangt. Op een capture van één kant lijken ze identiek. Om te bepalen welke van de twee u heeft, zijn drie controles nodig, en geen daarvan is het linkselectievenster.

Kiest u de verkeerde volgorde, dan stelt u bronselectie af om een identiteitsverschil te verhelpen. Zo wordt dezelfde tunnel twee keer gerepareerd en breekt hij na de volgende routewijziging weer.

Drie voorwaarden die de twee gevallen scheiden

Voorwaarde één: komt het geconfigureerde eindpunt van de peer overeen met het adres dat werkelijk aankomt? Als pakketten de externe gateway bereiken vanaf een adres dat deze niet aan uw peer-object koppelt, mislukt de onderhandeling voordat er ooit een identiteit wordt uitgewisseld. Voorwaarde twee: komt de IKE-identiteit in het voorstel overeen met de waarde die de peer verwacht? Dat is authenticatie, geen transport. Voorwaarde drie: is de optie die u wilt wijzigen ondersteund voor dit virtuele systeem op deze release? Geen enkele zichtbare instelling beantwoordt deze vragen.

Als voorwaarde één faalt, hebt u een routerings- of vertaalprobleem. Als voorwaarde twee faalt, hebt u een probleem met het peer-contract. Als voorwaarde drie onbekend is, stop dan met configureren.

Stel eerst het record van de externe peer op

Noteer het virtuele systeem, de softwareversie en het geïnstalleerde updateniveau voordat u iets aanraakt. Leg daarna de externe interfaces vast, de route naar de externe peer, de verwachte bronadressen voor en na NAT, en het geconfigureerde eindpunt van de externe peer.

Houd de interne beschermde prefixen in een apart deel van dat record. Een externe bron wijzigen en een beschermd LAN-adres wijzigen zijn verschillende bewerkingen die toevallig in hetzelfde beleid staan.

Voeg richting toe aan elke capture die u bewaart. Een lokaal gestarte onderhandeling en een antwoord aan de externe peer kunnen anders selecteren, dus een capture zonder label is zwak bewijs. Label het bestand met het virtuele systeem en de initiator.

Lees wat linkselectie werkelijk scheidt

De handleiding van Check Point over linkselectie in R81.20 scheidt drie dingen die mensen samenvoegen tot één: hoe de externe peer een gatewayadres resolveert, welke route het uitgaande verkeer draagt en welke bron-IP wordt gebruikt. Elk beantwoordt een andere vraag. Geen ervan verandert de identiteit die de peer authenticeert.

Die scheiding verklaart waarom een routewijziging het zichtbare externe adres kan veranderen zonder de IKE-identiteit aan te raken, en waarom een identiteitswijziging een tunnel kan breken waarvan de routering perfect is.

RFC 7296 trekt dezelfde grens voor IKE zelf: de identificatie-payload is niet het transportadres. Leveranciers implementeren die splitsing, ze herdefiniëren haar niet.

Beslis op bewijs, niet op het instellingenvenster

Meldt de peer een onbekende of niet-overeenkomende identiteit, herstel dan het peer-object of de identiteitsconfiguratie, niet de bronselectie. Meldt de peer niets en toont uw capture pakketten die van een onverwacht adres vertrekken, herstel dan eerst routering of vertaling. Lijken beide juist en faalt de tunnel nog steeds, maak dan een capture aan de externe kant en vergelijk wat die heeft ontvangen. Pas wanneer adres en identiteit overeenkomen en het pad nog steeds fout is, wordt een linkselectie-optie kandidaat.

Voordat u die optie op VSX configureert, vraagt u de richtlijnen over ondersteunde functies van de betreffende release op, of een uitdrukkelijke verklaring van de leverancier voor de context van het virtuele systeem. Een ouder rapport dat een functie niet beschikbaar was, is geschiedenis, geen huidig verbod, en een instellingenvenster is geen supportverklaring.

Breng beide uiteinden in overeenstemming en bewaar het record

Zodra u een ondersteund ontwerp hebt, beoordeelt u externe bereikbaarheid, de eindpuntconfiguratie van de peer en de identiteitsafspraak samen, als één contract. Plan daarna de acceptatie voor drie gevallen: de eerste verbinding, een verbinding die door de externe kant wordt gestart, en de storing die u verwacht wanneer het pad breekt.

Bewaar de waargenomen externe adressen naast de context van het actieve virtuele systeem. De volgende routewijziging vergelijkt dan met een gedocumenteerd contract in plaats van met iemands herinnering aan de standaardwaarde.