Fast VPN-IP: Framed-IP-Address i RADIUS eller ei reservasjon i poolen

Tre stader kan halde ei fast indre adresse for ein VPN-klient, og berre ein av dei bør eige ho. RADIUS kan returnere adressa i ein Access-Accept, gatewayen kan halde ei statisk tildeling for kontoen, og klientadapteren kan setjast manuelt. Dei to fyrste er policy, og den tredje er ei lokal gissing som gatewayen står fritt til å ignorere eller skrive over. Valet mellom dei to fyrste er den verkelege avgjerda, og ho avheng av kva nettverkstilgangsserveren faktisk implementerer.

Tre stader ei fast adresse kan bu

RADIUS eig adressa når svaret ber Framed-IP-Address og gatewayen brukar den verdien på sesjonen. Gatewayen eig ho når ein administrator tildeler kontoen til ei statisk adresse i poolen. Klienten eig ingenting, sjølv når adapteren viser ei manuell adresse, fordi serveren tildeler den indre adressa under forhandlinga, og ei lokal innstilling tyder berre noko når serveren ikkje sender noka. Alle tre ser identiske ut på ei fungerande tilkopling, og difor dukkar konfliktar opp seint. Skilnaden syner seg ved attoppkopling, på ein annan eining og etter ei policyendring.

To eigarar er den konfigurasjonen som ryker. Eit RADIUS-svar som tildeler 172.28.4.77 medan gatewayen har ei statisk tildeling til 172.28.4.90, gjev den verdien som koden til leverandøren sjekkar fyrst, og taparen blir forkasta utan ei logglinje. Same konto på ei anna eining får då ei duplikatadresse, og symptomet blir lese som ein rutefeil snarare enn ein tildelingskonflikt. Avgjer eigaren før du legg til den andre mekanismen.

Klientalternativet er berre verdt å nemne for å kunne utelukke det. Ei manuell adapteradresse er ei preferanse operativsystemet kan vise, ikkje ein reservasjon, og ho kan ikkje hindre ein annan sesjon i å få same adresse.

Kva RADIUS-svaret kan og ikkje kan love

RFC 2865definerer Framed-IP-Address som IPv4-adressa som skal konfigurerast for brukaren, og ho høyrer i Access-Accept. Same attributt i Access-Request er berre eit hint serveren kan ignorere, og det tyder noko når ein klient eller gateway tilbyr ei føretrekt adresse. Ingenting i protokollen tvingar gatewayen til å ære svaret, fordi nettverkstilgangsserveren er komponenten som brukar det på sesjonen.

Støtte er eit produktspørsmål og ikkje eit protokollspørsmål. Nokre gatewayar brukar innrama adresser som standard, andre treng ein brytar på gruppenivå slått på før dei gjer det, og atter andre godtar attributtet og brukar det aldri for fjernaksesesjonar. Det siste tilfellet er det farlege, fordi rekneskapsposten kan vise svaret medan klienten får ei pooladresse. Stadfest åtferda på den nøyaktige gatewaymodellen og fastvaren du køyrer, ikkje i dokumentasjonen til eit systerprodukt.

Eit svar gatewayen ignorerer ser nøyaktig ut som eit svar som aldri vart sendt. Å lese Access-Accept og adressa til sesjonen side om side er den einaste måten å skilje dei to tilfella.

Reserver adressa i poolen du allereie rutar

Vel den faste adressa frå undernettet til poolen som gatewayen allereie rutar og som brannmuren allereie stolar på. Ei adresse utanfor det området gjer ei policyendring til eit ruteprosjekt, og VPN kjem opp medan ingenting bak han kan svare. Viss det finst tilgangsreglar per adresse, legg den faste adressa til dei i same endring.

Avgjer kva ein andre samstundes sesjon skal gjere. Å tildele éi adresse to gonger er ikkje einingstyring, og kollisjonen som oppstår viser seg som periodisk tilkopling for båe sesjonane. Utferd anten ulike identitetar per eining, ulike tildelingar, eller krev samstundesheit med ein støtta sjekk, som til dømes Simultaneous-Use, i staden for å håpe at klienten aldri koplar til på nytt før den gamle sesjonen renn ut.

Returruter fortener same merksemd som tildelinga. Gatewayen treng ei rute til poolen, dei interne rutarane treng ei rute tilbake til gatewayen, og den faste adressa arvar båe. Éin klient som verkar medan alle andre feilar, tyder vanlegvis at poolruta finst, men at vertsruta for den reserverte adressa ikkje gjer det.

Test svaret før du stolar på reservasjonen

Test AAA-sida og sesjonssida kvar for seg, fordi dei feilar av ulike grunnar. Ein lokal radtest viser kva serveren returnerer for kontoen utan å involvere gatewayen, og oppføringa i brukarfila viser kva serveren skal matche. Kopla deretter klienten til på nytt og samanlikn adressa han fekk med attributtet 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

Ein Access-Accept utan attributtet tyder at serveren ikkje matcha oppføringa, eller at attributtet ikkje vart brukt på den brukaren. Ein Access-Accept med attributtet og ein klient som framleis får ei pooladresse, tyder at gatewayen ignorerte det. Ein Access-Reject sender deg tilbake til påloggingsinformasjonen eller gruppepolicyen, og ingen av desse utfalla bør feilsøkjast ved å redigere klientadapteren.

Gjenta sjekken etter ei attoppkopling og etter ei anna pålogging frå ei anna eining. Ein reservasjon som berre held for den fyrste sesjonen, er ein poolkonflikt som ventar på å skje, og det er billegare å finne han no enn under ein revisjon.

Vel éin eigar og skriv han ned

Viss gatewayen brukar innrama adresser påliteleg, la RADIUS eige tildelinga og fjern kvar statisk tildeling for same konto. Viss ikkje, la gatewayen eige ho og fjern attributtet frå svaret, slik at dei to kjeldene ikkje kan vere usamde. Å halde båe fordi kvar av dei nesten verkar, garanterer ein framtidig sesjon med feil adresse og utan openberr årsak.

Skriv den valde eigaren, den reserverte adressa og poolen ho kom frå i kontoposten. Den neste personen som legg til ei eining, kan då sjå om adressa er ein AAA-policy eller ei gatewaytildeling før vedkomande endrar nokon av dei.