Fast VPN-IP: RADIUS Framed-IP-Address eller en reservation i puljen

Tre steder kan holde en fast indre adresse til en VPN-klient, og kun ét af dem bør eje den. RADIUS kan returnere adressen i en Access-Accept, gatewayen kan holde en statisk mapping for kontoen, og klientadapteren kan sættes manuelt. De to første er politik, og det tredje er et lokalt gæt, som gatewayen frit kan ignorere eller overskrive. Valget mellem de to første er den egentlige beslutning, og det afhænger af, hvad netværksadgangsserveren faktisk implementerer.

Tre steder en fast adresse kan bo

RADIUS ejer adressen, når svaret bærer Framed-IP-Address, og gatewayen anvender den værdi på sessionen. Gatewayen ejer den, når en administrator mapper kontoen til en statisk adresse i puljen. Klienten ejer intet, selv når dens adapter viser en manuel adresse, fordi serveren tildeler den indre adresse under forhandlingen, og en lokal indstilling betyder kun noget, når serveren ikke sender nogen. Alle tre ser identiske ud på en fungerende forbindelse, og derfor dukker konflikter sent op. Forskellen viser sig ved genopkobling, på en anden enhed og efter en politikændring.

To ejere er den konfiguration, der brækker. Et RADIUS-svar, der tildeler 172.28.4.77, mens gatewayen har en statisk mapping til 172.28.4.90, giver den værdi, som leverandørens kode tjekker først, og taberen kasseres uden en loglinje. Den samme konto på en anden enhed modtager derefter en dubletadresse, og symptomet læses som en routingfejl snarere end en tildelingskonflikt. Afgør ejeren, før du tilføjer den anden mekanisme.

Klientmuligheden er kun værd at nævne for at kunne udelukke den. En manuel adapteradresse er en præference, som styresystemet kan vise, ikke en reservation, og den kan ikke forhindre en anden session i at få den samme adresse.

Hvad RADIUS-svaret kan og ikke kan love

RFC 2865definerer Framed-IP-Address som den IPv4-adresse, der skal konfigureres for brugeren, og den hører i Access-Accept. Den samme attribut i Access-Request er kun et hint, som serveren kan ignorere, og det betyder noget, når en klient eller gateway tilbyder en foretrukken adresse. Intet i protokollen tvinger gatewayen til at ære svaret, fordi netværksadgangsserveren er den komponent, der anvender det på sessionen.

Support er et produktspørgsmål snarere end et protokolspørgsmål. Nogle gatewayer anvender indrammede adresser som standard, nogle skal have en kontakt på gruppeniveau slået til, før de vil, og nogle accepterer attributten og bruger den aldrig til fjernadgangssessioner. Det sidste tilfælde er det farlige, fordi regnskabsposten kan vise svaret, mens klienten modtager en puljeadresse. Bekræft adfærden på den præcise gatewaymodel og firmware, du kører, ikke i dokumentationen for et søsterprodukt.

Et svar, som gatewayen ignorerer, ser præcis ud som et svar, der aldrig blev sendt. At læse Access-Accept og sessionens adresse side om side er den eneste måde at skelne de to tilfælde.

Reservér adressen inde i den pulje, du allerede router

Vælg den faste adresse fra puljens undernet, som gatewayen allerede router, og som firewallingen allerede stoler på. En adresse uden for det område gør en politikændring til et routingprojekt, og VPN’en kommer op, mens intet bag den kan svare. Hvis der findes adgangsregler pr. adresse, skal den faste adresse føjes til dem i samme ændring.

Beslut, hvad en anden samtidig session skal gøre. At tildele én adresse to gange er ikke enhedsstyring, og den resulterende kollision viser sig som periodisk forbindelse for begge sessioner. Udsted enten forskellige identiteter pr. enhed, forskellige tildelinger, eller håndhæv samtidighed med et understøttet tjek som f.eks. Simultaneous-Use i stedet for at håbe på, at klienten aldrig genopkobler, før den gamle session udløber.

Returruter fortjener samme opmærksomhed som tildelingen. Gatewayen har brug for en rute til puljen, de interne routere har brug for en rute tilbage til gatewayen, og den faste adresse arver begge. En enkelt klient, der virker, mens alle andre fejler, betyder normalt, at puljeruten findes, men at værtsruten for den reserverede adresse ikke gør.

Test svaret, før du stoler på reservationen

Test AAA-siden og sessionssiden hver for sig, fordi de fejler af forskellige grunde. En lokal radtest viser, hvad serveren returnerer for kontoen uden at inddrage gatewayen, og posten i brugerfilen viser, hvad serveren skal matche. Genopkobl derefter klienten, og sammenlign den adresse, den modtog, med attributten i svaret.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

En Access-Accept uden attributten betyder, at serveren ikke matchede posten, eller at attributten ikke blev anvendt på den bruger. En Access-Accept med attributten og en klient, der stadig modtager en puljeadresse, betyder, at gatewayen ignorerede den. En Access-Reject sender dig tilbage til loginoplysningerne eller gruppepolitikken, og ingen af disse udfald bør fejlfindes ved at redigere klientadapteren.

Gentag tjekket efter en genopkobling og efter et andet login fra en anden enhed. En reservation, der kun holder til den første session, er en puljekonflikt, der venter på at ske, og det er billigere at finde den nu end under en revision.

Vælg én ejer, og skriv den ned

Hvis gatewayen anvender indrammede adresser pålideligt, så lad RADIUS eje tildelingen, og fjern enhver statisk mapping for den samme konto. Hvis ikke, så lad gatewayen eje den, og fjern attributten fra svaret, så de to kilder ikke kan være uenige. At beholde begge, fordi hver især næsten virker, garanterer en fremtidig session med den forkerte adresse og uden åbenlys årsag.

Skriv den valgte ejer, den reserverede adresse og den pulje, den kom fra, i kontoposten. Den næste person, der tilføjer en enhed, kan så se, om adressen er en AAA-politik eller en gateway-mapping, før vedkommende ændrer nogen af dem.