IPsec over een privé-WAN: SRX-beleidsgrenzen om te controleren

Een privé-WAN kan de buitenste pakketten van een IPsec-tunnel dragen, dus de peer-adressen hoeven geen openbare internetadressen te zijn. Wat verandert, is het pad dat die buitenste pakketten nemen en de machtigingen op de interface die ze ontvangt. Op een SRX zijn het buitenste controlepad, de binding van de tunnelinterface en het beleid voor doorgestuurd verkeer drie afzonderlijke objecten. Probleemoplossing op één terwijl de andere twee fout zijn, is de gebruikelijke reden dat een tunnel down blijft.

Leg eerst het buitenste IKE-pad vast

Noteer vier waarden voordat u het beleid aanraakt: het peer-adres, de lokale interface die IKE ontvangt, de routeringscontext die de peer bereikt en de route die die interface selecteert. IKE-pakketten zijn aan de SRX zelf gericht, dus ze hebben host-inbound-machtiging nodig in de ontvangende zone, niet een beleid voor doorgestuurd verkeer. Een privé-WAN-adres heft die eis niet op, omdat het pakket nog steeds op het apparaat eindigt.

Controleer de geïnstalleerde status met show security ike sa en de configuratie met show configuration security ike. De eerste laat zien of fase 1 bestaat; de tweede laat zien wat het apparaat denkt te moeten doen.

Bind de tunnelinterface aan het juiste beleid

Een routegebaseerde VPN bindt een tunnelinterface aan een VPN-object, en beveiligde prefixen worden naar die interface gerouteerd. Noteer welke interface, welke route en welk beleid de toepassingen tussen de relevante zones toestaan. Een zone met de naam trust is een beleidscontainer, en de naam bewijst niet dat de vereiste controle- of datapakketten zijn toegestaan.

Lees de werkelijke bindingen in plaats van een oud diagram: show configuration security ipsec vpn voor de instelling bind-to-interface en show configuration security policies voor de regels die naar de tunnelzone verwijzen.

Als de beveiligde route ergens anders heen wijst, kan de tunnel omhoog zijn terwijl het verkeer er nooit in komt. Dat is een routeringsprobleem in een IPsec-kostuum.

Houd de peer-route op de underlay

De route naar de externe peer moet via de underlay worden opgelost, niet recursief via de tunnel die hij opzet. Als de peer-route naar de tunnelinterface wijst, jagen IKE-pakketten hun eigen tunnel achterna en fase 1 wordt nooit voltooid. Het retourpad voor beveiligd verkeer heeft zijn eigen correcte route en beleid nodig, en dat is meestal de ontbrekende helft wanneer één richting werkt. Lees de routetabelvermelding voor het peer-adres en bevestig dat de uitgaande interface de WAN-interface is.

Controleer het met show route 198.51.100.10, met het echte peer-adres ingevuld, en bevestig dat de volgende hop geen tunnelinterface is.

Verifieer controle en dienst in volgorde

Werk omhoog: status van fase 1, status van fase 2 en dan een echte applicatiestroom. show security ipsec sa vermeldt de beveiligingsassociaties, en show security flow session destination-prefix 10.60.0.0/16 laat zien of doorgestuurde sessies voor het beveiligde netwerk worden aangemaakt.

Een gezonde controlerelatie en een werkend datapad zijn twee verschillende resultaten, en een geslaagde fase 2 zegt niets over of het beleid de toepassing toestaat. Test één toegestane stroom en één die het beleid zou moeten weigeren, zodat het verschil zichtbaar is.

Noteer de peer-route, de host-inbound-machtiging, de tunnelbinding, de interne route en het toepassingsbeleid samen. Die vijf registraties laten zien welke laag eigenaar is van een toekomstige storing zonder op een poortlabel te vertrouwen.