CIDR van een Access Server-groep: ledenadressen of resourcenetwerk

In een Access Server-groep accepteren twee velden een CIDR en op het eerste gezicht lijken ze hetzelfde soort invoer: het ene beschrijft de adressen die VPN-leden krijgen, het andere de netwerken die die leden kunnen bereiken. Het verkeerde veld invullen wordt zonder fout geaccepteerd, en dat is precies wat de fout duur maakt. Het eerste verandert je adresseerplan voor de tunnel, het tweede bepaalt welke bestemmingen zijn toegestaan, en geen van beide impliceert het andere. Er is ook een derde object dat mensen hierbij voegen, het subnet achter de gateway van een vestiging, en dat hoort bij geen van beide velden.

Dezelfde syntaxis, andere vragen

Vraag wat de waarde benoemt. Een CIDR met ledenadressen beantwoordt de vraag welke interne adressen verbindende clients krijgen, en de toewijzingsmachinerie gebruikt hem voordat er verkeer stroomt. Een resource-CIDR beantwoordt welke bestemmingen deze groep mag gebruiken, en de toegangsregels gebruiken hem bij het beoordelen van een pakket. Het ene is een pooldefinitie, het andere een toestemming.

De gevolgen van verwisseling zijn tegengesteld. Een doellAN die in het poolveld wordt geplakt kan adressen uitdelen die al op dat netwerk bestaan en dubbel adresgedrag veroorzaken, of de pool verschuiven waardoor alle firewallregels die voor het oude bereik zijn geschreven stilzwijgend breken. Een pool die in een toegangsregel wordt geplakt levert niets bruikbaars op, omdat er geen bestemming woont. Beide fouten zien er hetzelfde uit: de tunnel staat, maar er is iets mis.

Toewijzing: de adresruimte van de leden

De pool mag niet overlappen met elk netwerk dat een lid kan bereiken en ook niet met een andere VPN-pool in de uitrol. Dit is een ontwerpbeperking, geen productinstelling: als twee locaties beide 10.90.40.0/24 voor leden gebruiken, kan een lid van de ene locatie niet naar de andere routeren zonder vertaling, en geen toegangsregel lost dat op.

De toewijzingsmodus is ook belangrijk. Een dynamische pool geeft elk lid het volgende vrije adres, terwijl een statische toewijzing per gebruiker het vastzet. Statische toewijzing is wat je wilt wanneer firewallregels of monitoring naar individuele leden verwijzen, en het maakt een wijziging van het adresseerplan zichtbaar: het vastgezette adres valt nog binnen de nieuwe pool of niet. Lees het tunneladres van een verbonden lid voor en na elke wijziging in dit veld.

Toestemming: doelnetwerken horen in toegangsregels

Bereikbaarheid wordt uitgedrukt in de toegangsregels, die de groep of gebruikers, een doelnetwerk of dienst en de toegangsmethode benoemen. Dat laatste deel is waar de meeste half afgemaakte configuraties sterven: een regel kan verkeer naar de bestemming routeren of het NATen, en die twee vragen verschillende dingen van het netwerk. Een gerouteerd pad vereist dat de bestemmingszijde weet hoe het verkeer terug naar de VPN-pool moet, terwijl een NAT-pad de leden verbergt achter een adres dat de bestemming al vertrouwt. De documentatie over Access Server-groepen houdt het groepsnetwerk gescheiden van de toegangsregels van de groep, en de labels zijn tussen releases verschoven.

Een toegestane bestemming heeft nog steeds een bruikbaar pad nodig. De regel staat toe, de route levert, het terugpad antwoordt en de dienst op de host accepteert. Vier dingen, vier plaatsen om te kijken, en alleen de eerste woont in de toegangsregel. Een groene toestemming met een dode traceroute betekent meestal dat het terugpad op de gateway van de bestemming ontbreekt, niet dat de regel fout is.

Het derde object: een vestigingssubnet achter een gateway

Verklaren dat een bepaalde client eigenaar is van een subnet is een routeringsuitspraak over een locatie, geen adrestoewijzing en geen toestemming. In Access Server-termen is dit de ondersteunde gatewayconfiguratie voor een netwerk dat verbinding maakt, en die bestaat omdat een vestigingsrouter het netwerk achter zich kan aankondigen. Leden krijgen nog steeds adressen uit de pool, en ze hebben nog steeds een toegangsregel nodig om dat vestigingsnetwerk te gebruiken.

De drie gescheiden houden loont bij de beoordeling. Een vestigingssubnet dat als ledenadresruimte van de groep is vastgelegd ziet er op een schermafbeelding correct uit en breekt de toewijzing voor iedereen in de groep. Hetzelfde subnet dat alleen in een toegangsregel is vastgelegd geeft toegang zonder de eigendomsverklaring, zodat terugverkeer nergens heen kan. Zet elk object in zijn eigen kolom van het ontwerp en de fout is niet langer mogelijk.

Hoe je weet welk je bekijkt

Lees het label samen met zijn buren. Een veld naast een toewijzingsmodus, poolgrootte of override per gebruiker gaat over toewijzing. Een veld naast een groepsselector, een dienst of poort en een routeringsmethode gaat over toestemming. Releases hernoemen dingen, maar de buren blijven ongeveer op hun plaats, en daarom is de tekst van een oude schermafbeelding een slechte navigatiegids.

Controleer daarna met een lid in plaats van de hele groep: de effectieve groep, het toegewezen tunneladres en de regel die de beoogde bestemming autoriseert. Bevestig de route, de NAT of het gerouteerde pad, het terugverkeer en de toestemming van de dienst in die volgorde, en wijzig alleen het veld dat bij de aangetoonde afwijking past. Houd daarna de registraties van toewijzing en toestemming gescheiden, zodat een latere poolwijziging niet wordt gelezen als een wijziging in wat de groep kan bereiken.