CIDR i Access Server-gruppen: medlemsadresser eller destinationsnetværk

To felter i en Access Server-gruppe accepterer et CIDR, og ved første øjekast ser de ud som samme slags input: det ene beskriver de adresser, der udleveres til VPN-medlemmer, det andet beskriver netværk, som disse medlemmer må nå. Udfylder man det forkerte felt, accepteres det uden fejl, og netop derfor bliver fejlen dyr. Det første ændrer din adresseplan for tunnelen, det andet afgør, hvilke destinationer der er tilladte, og ingen af dem forudsætter den anden. Der findes også et tredje objekt, som folk presser ind i disse to, nemlig subnettet bag en filialgateway, og det hører ikke hjemme i noget af felterne.

Samme syntaks, forskellige spørgsmål

Spørg, hvad værdien navngiver. Et medlemsadresse-CIDR svarer på "hvilke indre adresser får forbindende klienter", og tildelingsmekanismen bruger det, før der flyder nogen trafik. Et ressource-CIDR svarer på "hvilke destinationer må denne gruppe bruge", og adgangsreglerne bruger det, når en pakke evalueres. Det ene er en pooldefinition, det andet er en tilladelse.

Konsekvenserne af at forveksle dem er modsatrettede. Et destinations-LAN, der indsættes i poolfeltet, kan udlevere adresser, som allerede findes på det LAN, hvilket giver dubletadresseadfærd, eller det kan flytte poolen på en måde, der lydløst ødelægger hver firewallregel, der er skrevet mod det gamle interval. En pool, der indsættes i en adgangsregel, giver intet brugbart, fordi der ikke bor nogen destination der. Begge fejl viser sig som "tunnelen er oppe, men noget er galt".

Tildeling: medlemmernes adresseområde

Poolen skal være ikke-overlappende med hvert LAN, som et medlem må nå, og med enhver anden VPN-pool i udrulningen. Det er en planlægningsbegrænsning snarere end en produktindstilling: når to steder begge bruger 10.90.40.0/24 til medlemmer, kan et medlem på det ene sted ikke route til det andet uden oversættelse, og ingen adgangsregel retter op på det.

Tildelingstilstanden betyder også noget her. En dynamisk pool giver hvert medlem den næste ledige adresse, mens en statisk tildeling pr. bruger fastlåser den. Statiske tildelinger er det, du vil have, når firewallregler eller overvågning henviser til enkelte medlemmer, og de gør også en ændring af adresseplanen synlig: den fastlåste adresse ligger enten stadig inde i den nye pool eller ikke. Læs tunneladressen for et tilsluttet medlem før og efter enhver ændring af dette felt.

Tilladelse: destinationsnetværk hører til i adgangsreglerne

Rækkevidde udtrykkes i adgangsreglerne, som angiver gruppen eller brugerne, et destinationsnetværk eller en service samt adgangsmetoden. Den sidste del er der, hvor de fleste halvfærdige opsætninger dør: en regel kan route trafik til destinationen eller NAT'e den, og de to kræver forskellige ting af netværket. En routed sti kræver, at destinationssiden ved, hvordan trafik skal returneres til VPN-poolen, mens en NAT-sti skjuler medlemmerne bag en adresse, som destinationen allerede stoler på. Dokumentationen for Access Server-grupper holder gruppenetværk adskilt fra gruppeadgangsregler, og betegnelserne har flyttet sig mellem versionerne.

En tilladt destination har stadig brug for en brugbar sti. Reglen tillader, ruten leverer, returvejen svarer, og servicen på værten accepterer. Fire ting, fire steder at kigge, og kun den første ligger i adgangsreglen. En grøn tilladelse med en død traceroute betyder som regel, at returruten mangler på destinationens gateway, og ikke at reglen er forkert.

Det tredje objekt: et filialsubnet bag en gateway

At erklære, at en bestemt klient ejer et subnet, er et routingudsagn om et sted, ikke en adressetildeling og ikke en tilladelse. I Access Server-termer er dette den understøttede gateway-konfiguration for et forbindende netværk, og den findes, fordi en filialrouter kan annoncere LAN'et bag sig. Medlemmerne modtager stadig adresser fra poolen, og de har stadig brug for en adgangsregel for at bruge det filial-LAN.

At holde de tre adskilt betaler sig under gennemgangen. Et filialsubnet, der er registreret som en gruppes medlemsadresseområde, ser korrekt ud på et skærmbillede og ødelægger tildelingen for alle i gruppen. Det samme subnet, der kun er registreret i en adgangsregel, giver adgang uden ejerskabserklæringen, så returtrafikken har ingen steder at gå hen. Sæt hvert objekt i sin egen kolonne i designet, og fejlen bliver umulig.

Sådan ser du, hvilket af dem du kigger på

Læs etiketten sammen med dens naboer. Et felt ved siden af en tildelingstilstand, en poolstørrelse eller en tilsidesættelse pr. bruger handler om tildeling. Et felt ved siden af en gruppevælger, en service eller port og en routingmetode handler om tilladelse. Versioner omdøber ting, men naboerne bliver nogenlunde, hvor de var, og derfor er ordlyden i et gammelt skærmbillede en dårlig navigationsvejledning.

Verificér derefter med ét medlem i stedet for hele gruppen: dets effektive gruppe, dets tildelte tunneladresse og reglen, der autoriserer dets tilsigtede destination. Bekræft ruten, NAT- eller routed-stien, returtrafikken og service-tilladelsen i den rækkefølge, og ændr kun det felt, der svarer til den påviste uoverensstemmelse. Hold tildelings- og tilladelsesposter adskilt bagefter, så en senere poolændring ikke læses som en ændring i, hvad gruppen må nå.