Stabil VPN-klientadresse med RADIUS Framed-IP-Address
En stabil VPN-adresse kræver RADIUS og en gateway, der respekterer attributten. Kontrollér forrangen, og sammenlign svaret med tunneladressen.
RADIUS kan svare med en adresse til en given bruger; om tunnelen faktisk modtager den, afhænger af gatewayen. Det er i dette gab mellem returneret og efterlevet, at de fleste planer for stabile adresser fejler. En attribut i et testsvar beviser, at serveren kan sende den, ikke at fjernadgangstjenesten anvender den. Sekvensen nedenfor kontrollerer begge halvdele, før adressen ender i firewallregler.
Afgør, hvilket lag der ejer adressen
Fjernadgangsgateways har normalt en lokal pulje, og mange kan også acceptere en adresse fra autentificeringssvaret. Hvilken der vinder, afhænger af platformen, protokollen og tjenestens konfiguration, så læs forrangsreglen for den præcise version, der bruges. Hvor den lokale pulje har forrang, er attributten ren dekoration, og klienten ender alligevel på en tilfældig adresse. Skriv beslutningen ned, inklusive om en returneret værdi skal ligge inden for puljeområdet eller må ligge uden for det.
RFC 2865 definerer Framed-IP-Address som den adresse, der skal konfigureres for brugeren, og siger intet om nogen bestemt gateways vilje til at efterleve den. Leverandørdokumentationen er autoriteten om forrang, ikke attributdefinitionen.
Send en testanmodning, og læs svaret
Test serveren isoleret først, så en manglende attribut ikke forveksles med et gatewayproblem. radtest sender én Access-Request og udskriver de attributter, der kommer tilbage.
radtest alice 'S3cret' 127.0.0.1 0 testing123Se efter Framed-IP-Address i Access-Accept, og bekræft, at værdien er den tilsigtede og ikke en puljeadresse fra en fallbackregel. Når attributten mangler, matcher brugerposten eller autorisationspolitikken ikke, og gatewayjustering kan ikke levere, hvad serveren aldrig sendte. Gentag anmodningen, mens serveren kører i fejlfindings-tilstand, hvis svaret er svært at spore til en bestemt regel. Hold den delte hemmelighed ude af shell-historik og tickets, fordi pladsholderen ovenfor ikke er en legitimationsoplysning.
Bekræft, at gatewayen efterlevede værdien
Et korrekt svar er kun halvdelen af aftalen. Adressen, der vises på tunnelinterfacet, er den observation, der betyder noget, og den aflæses på klienten i stedet for at blive udledt af gatewaykonfigurationen.
ip -4 addr show tun0Sammenlign den adresse med attributten fra Access-Accept. En uoverensstemmelse betyder, at gatewayen ignorerede eller omskrev værdien, hvilket genåbner forrangsspørgsmålet fra første afsnit. Genopret forbindelsen én gang mere, fordi en reservation, der kun virker i første forsøg, normalt peger på en forældet session eller en lease, som den forrige forbindelse stadig holder. Notér gatewayversion og protokol ved siden af resultatet, så den næste person kan afgøre, om adfærden er versionsspecifik.
Planlæg samtidighed og tilbagekaldelse
Ét brugernavn på to enheder kan ikke knyttes til én adresse, medmindre gatewayen skelner sessionerne ved noget ud over login. Afgør, om tilknytningen hører til en person, en registreret enhed eller en certifikatidentitet, og gør det valg eksplicit i politiklageret. Test en anden samtidig klient, og sammenlign begge tildelte adresser, fordi en kollision her senere dukker op som en routingfejl. Samme omhu hører i tilbagekaldelsesplanen, fordi en adresse, der tildeles igen, mens gamle firewallregler stadig henviser til den, bliver en autorisationsfejl.
Stabil adressering forenkler regler og logfiler, men beviser aldrig, hvem der genererede en pakke. Autentificering og destinationsautorisation betyder stadig noget, når adressen senere flytter til en anden session.