Een brede IPsec-selector is geen toestemming voor elke dienst

Twee peers spreken af een heel subnet te beschermen, en iemand leest die afspraak als toestemming om elke dienst erbinnen te bereiken. Dat is de mythe: de selector zegt welk verkeer de tunnel bereid is te dragen, en hij zegt niets over welke diensten de organisatie toestaat. Een paar apparaten kan legitiem een breed adresbereik onderhandelen terwijl het toegangsbeleid erbinnen twee poorten toestaat, en beide uitspraken blijven tegelijk waar.

Beschermde dekking is geen autorisatie

Een verkeersselector maakt deel uit van de tunnelafspraak. Hij vernauwt of bevestigt wat de peers tussen elkaar versleutelen, en een brede selector is vaak het eenvoudigst te beheren wanneer beide kanten veel stromen te dragen hebben. Het dienstfilter is een andere controle op een ander punt in het pad, en het beslist wat er na ontsleuteling werkelijk gebruikt mag worden. Het filter weghalen om één test te laten slagen maakt van een beleidsbeslissing een ongeluk.

Houd de twee registraties apart in het ontwerpdocument, want een lezer die alleen de selector ziet, leidt autorisatie af die nooit is verleend. Twee regels in een wijzigingsregistratie voorkomen dat, en ze kosten minder tijd dan de discussie die volgt.

Beschrijf één stroom vanaf beide kanten

Schrijf de initiator, de responder, de bron en bestemming zoals aangeboden, het protocol en beide poorten op. Keer daarna elk van die labels om voor het andere eindpunt, want de tijdelijke bronpoort van een client wordt de bestemmingspoort van een antwoord en het externe netwerk wordt het lokale. Een configuratie die van de ene kant naar de andere is gekopieerd zonder die ommekeer, is hoe filters uiteindelijk precies de verkeerde richting toestaan. Schrijf de tabel één keer en bouw beide filters daaruit.

Spreek het selectiemodel af voordat u iets kopieert, want een beleidsgebaseerd ontwerp en een routegebaseerd ontwerp drukken dezelfde bedoeling uit via verschillende objecten. Schrijf de modelnaam naast de stroom, anders besteedt de volgende engineer een middag aan het matchen van objecten die nooit vergelijkbaar waren.

Vind het filter dat werkelijk van toepassing is

Op een ASA is het VPN-filter een ACL die aan een groepbeleid hangt en wordt toegepast op verkeer na ontsleuteling en vóór versleuteling. De groepbeleidsdocumentatie van Cisco beschrijft ook overerving, inclusief een waarde op gebruikersniveau die de waarde van het groepbeleid vervangt. De ACL die u hebt bewerkt is dus misschien niet de ACL die de sessie voor u beheert. Hetzelfde geldt voor het gebruikersobject, dat de groep kan overschrijven zonder veel zichtbaar bewijs achter te laten.

Onderzoek de effectieve sessie in plaats van het object waarvan u zich herinnert dat u het hebt gewijzigd, en noteer welk beleidsobject die levert. Die ene stap lost een verrassend aantal meldingen op van het type „het filter klopt, maar het werkt niet“.

Richting, poorten en het omgekeerde geval

De gedocumenteerde conventie plaatst het externe netwerk, of de toegewezen externe clientadressen, op de bronpositie en het lokale netwerk op de bestemmingspositie, waarbij antwoorden worden uitgedrukt door de adresposities om te wisselen. Poortregels liggen bovenop die conventie en verdienen meer zorg dan de adressen.

Het gedocumenteerde model kan een bestemmingspoortregel van invloed laten zijn op omgekeerde initiatie die dezelfde bronpoort gebruikt, wat betekent dat het filter niet simpelweg een eenrichtingsregel voor verzoeken met onschadelijke antwoorden is. Redeneer expliciet door beide initiatierichtingen, en neem het geval op dat u van plan bent te weigeren.

Dezelfde documentatie beperkt het filter tot initiële verbindingen, dus het is geen universele handhaving van elk secundair kanaal dat een geïnspecteerde toepassing opent. Waar het volledige beleid die dekking nodig heeft, hoort die bij een aparte grens in plaats van in een ACL die voorbij zijn doel wordt gerekt.

Test drie gevallen voordat u het klaar noemt

Accepteer de bedoelde stroom, weiger een dienst die het beleid verbiedt, en oefen het omgekeerde-richtinggeval waarover u hebt geredeneerd. Voer ze uit onder een goedgekeurd plan met dezelfde identiteiten en selectors die u gaat uitrollen. Een test die alleen laat zien dat de toegestane dienst werkt, toont de tunnel aan, niet het beleid.

Houd de onderhandelde dekking en de toegangsbeslissing als twee registraties, want om uit te leggen wat een VPN toestaat zijn beide nodig.