IPsec oor 'n privaat WAN: SRX-beleidsgrense om na te gaan

'n Privaat WAN kan die buitenste pakkette van 'n IPsec-tonnel dra, so die peer-adresse hoef nie openbare internetadresse te wees nie. Wat verander, is die pad wat dié buitenste pakkette volg en die toestemmings op die koppelvlak wat hulle ontvang. Op 'n SRX is die buitenste beheerpad, die tonnelkoppelvlakbinding en die beleid vir geforwarde verkeer drie afsonderlike objekte. Om een te ontfout terwyl die ander twee verkeerd is, is die gewone rede waarom 'n tonnel af bly.

Teken eers die buitenste IKE-pad aan

Skryf vier waardes neer voordat jy aan die beleid raak: die peer-adres, die plaaslike koppelvlak wat IKE ontvang, die roeteringskonteks wat by die peer uitkom en die roete wat daardie koppelvlak kies. IKE-pakkette word aan die SRX self geadresseer, so hulle benodig host-inbound-toestemming op die ontvangende sone, nie 'n beleid vir geforwarde verkeer nie. 'n Privaat WAN-adres verwyder nie daardie vereiste nie, want die pakket eindig steeds op die toestel.

Kontroleer die geïnstalleerde toestand met show security ike sa en die konfigurasie met show configuration security ike. Die eerste sê of fase 1 bestaan; die tweede sê wat die toestel dink hy behoort te doen.

Bind die tonnelkoppelvlak aan die regte beleid

'n Roetebegebaseerde VPN bind 'n tonnelkoppelvlak aan 'n VPN-objek, en beskermde prefikse word in daardie koppelvlak ingeroeteer. Teken aan watter koppelvlak, watter roete en watter beleid die toepassings tussen die betrokke sones toelaat. 'n Sone met die naam trust is 'n beleidshouer, en die naam bewys nie dat die nodige beheer- of datapakkette toegelaat word nie.

Lees die werklike bindings eerder as 'n ou diagram: show configuration security ipsec vpn vir die bind-to-interface-instelling en show configuration security policies vir die reëls wat na die tonnelsone verwys.

As die beskermde roete na elders wys, kan die tonnel op wees terwyl verkeer nooit daarin kom nie. Dit is 'n roeteringsprobleem in 'n IPsec-kostuum.

Hou die peer-roete op die onderlaag

Die roete na die eksterne peer moet deur die onderlaag opgelos word, nie rekursief deur die tonnel wat dit vestig nie. As die peer-roete na die tonnelkoppelvlak wys, jaag IKE-pakkette hul eie tonnel en voltooi fase 1 nooit nie. Die antwoordpad vir beskermde verkeer het sy eie korrekte roete en beleid nodig, en dit is gewoonlik die ontbrekende helfte wanneer een rigting werk. Lees die roetetabel-inskrywing vir die peer-adres en bevestig dat die uitgaande koppelvlak die WAN-koppelvlak is.

Kontroleer dit met show route 198.51.100.10, met die werklike peer-adres ingevul, en bevestig dat die volgende hop nie 'n tonnelkoppelvlak is nie.

Verifieer beheer en diens in volgorde

Werk opwaarts: fase 1-toestand, fase 2-toestand en dan 'n werklike toepassingsvloei. show security ipsec sa lys die sekuriteitsassosiasies, en show security flow session destination-prefix 10.60.0.0/16 wys of geforwarde sessies vir die beskermde netwerk geskep word.

'n Gesonde beheerverhouding en 'n werkende datapad is twee verskillende resultate, en 'n geslaagde fase 2 sê niks oor of die beleid die toepassing toelaat nie. Toets een toegelate vloei en een wat die beleid behoort te verwerp, sodat die verskil sigbaar is.

Teken die peer-roete, die host-inbound-toestemming, die tonnelbinding, die binneste roete en die toepassingsbeleid saam aan. Daardie vyf aantekeninge wys watter laag 'n toekomstige fout besit sonder om op 'n poortetiket te staatmaak.