Dvije različite promjene daju isti simptom kada Check Point tunel od lokacije do lokacije prestane da se podiže: peer vidi drugu vanjsku adresu ili odbija IKE identitet koji sada prima. Na snimku s jedne strane oboje izgleda isto. Da utvrdite koji od dva slučaja imate, potrebne su tri provjere i nijedna od njih nije panel za odabir linka.

Ako pogriješite redoslijed, podešavate odabir izvora da popravite nepodudarnost identiteta. Tako se isti tunel popravlja dvaput i ponovo pada nakon sljedeće promjene rute.

Tri uslova koja razdvajaju dva slučaja

Uslov prvi: da li se konfigurisana krajnja tačka peera poklapa s adresom koja zaista dolazi? Ako paketi stižu do udaljenog gatewaya s adrese koju on ne povezuje s vašim peer objektom, pregovaranje pada prije razmjene bilo kakvog identiteta. Uslov drugi: da li se IKE identitet u predlogu poklapa s vrijednošću koju peer očekuje? To je autentifikacija, ne transport. Uslov treći: da li je opcija koju želite promijeniti podržana za ovaj virtuelni sistem na ovom izdanju? Nijedno vidljivo podešavanje ne odgovara na ova pitanja.

Ako prvi uslov ne prolazi, imate problem s rutiranjem ili translacijom. Ako drugi ne prolazi, imate problem s ugovorom s peerom. Ako je treći nepoznat, zaustavite konfigurisanje.

Prvo sastavite zapis o vanjskom peeru

Zapišite virtuelni sistem, izdanje softvera i instalirani nivo ažuriranja prije nego što bilo šta dirnete. Zatim zabilježite vanjske interfejse, rutu prema udaljenom peeru, očekivane izvorne adrese prije i poslije NAT-a i konfigurisanu krajnju tačku udaljenog peera.

Držite unutrašnje zaštićene prefikse u odvojenom dijelu tog zapisa. Promjena vanjskog izvora i promjena zaštićene LAN adrese dvije su različite operacije koje slučajno žive u istoj politici.

Dodajte smjer svakom snimku koji čuvate. Lokalno inicirano pregovaranje i odgovor udaljenom peeru mogu birati različito, pa je snimak bez oznake slab dokaz. Označite datoteku virtuelnim sistemom i inicijatorom.

Pročitajte šta odabir linka zapravo razdvaja

Check Point vodič za odabir linka u R81.20 razdvaja tri stvari koje ljudi spajaju u jednu: kako udaljeni peer razrješava adresu gatewaya, koja ruta nosi odlazni saobraćaj i koja se izvorna IP adresa koristi. Svaka odgovara na drugo pitanje. Nijedna od njih ne mijenja identitet koji peer autentifikuje.

To razdvajanje objašnjava zašto promjena rute može promijeniti vidljivu vanjsku adresu bez diranja IKE identiteta i zašto promjena identiteta može srušiti tunel čije je rutiranje besprijekorno.

RFC 7296 povlači istu granicu za sam IKE: identifikacijski payload nije transportna adresa. Proizvođači implementiraju tu podjelu, ne redefinišu je.

Odluku donosite dokazima, a ne panelom podešavanja

Ako peer prijavi nepoznat ili neusklađen identitet, popravite peer objekat ili konfiguraciju identiteta, a ne odabir izvora. Ako peer ne prijavi ništa, a vaš snimak pokazuje pakete koji izlaze s neočekivane adrese, prvo popravite rutiranje ili translaciju. Ako oboje izgleda ispravno, a tunel i dalje ne radi, snimite na udaljenoj strani i uporedite šta je primila. Tek kada se adresa i identitet slažu, a put je i dalje pogrešan, opcija iz odabira linka postaje kandidat.

Prije nego što tu opciju konfigurišete na VSX-u, pribavite smjernice o podržanim funkcijama za odgovarajuće izdanje ili izričitu izjavu proizvođača za kontekst virtuelnog sistema. Stariji izvještaj da funkcija nije bila dostupna je historija, a ne trenutna zabrana, i panel podešavanja nije izjava o podršci.

Uskladite oba kraja i čuvajte zapis

Kada imate podržan dizajn, pregledajte vanjsku dostupnost, konfiguraciju krajnje tačke peera i saglasnost o identitetu zajedno, kao jedan ugovor. Zatim planirajte prihvat za tri slučaja: početnu vezu, vezu koju inicira udaljena strana i kvar koji očekujete kada se put prekine.

Sačuvajte zapažene vanjske adrese uz kontekst aktivnog virtuelnog sistema. Sljedeća promjena rute tada se poredi s dokumentovanim ugovorom, a ne s nečijim sjećanjem na podrazumijevanu vrijednost.

Povezani članci