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

Tre steder kan holde en fast indre adresse for en VPN-klient, og bare ett av dem bør eie den. RADIUS kan returnere adressen i en Access-Accept, gatewayen kan holde en statisk tilordning for kontoen, og klientadapteren kan settes manuelt. De to første er policy, og det tredje er en lokal gjetning som gatewayen står fritt til å ignorere eller overskrive. Valget mellom de to første er den virkelige beslutningen, og det avhenger av hva nettverkstilgangsserveren faktisk implementerer.

Tre steder en fast adresse kan bo

RADIUS eier adressen når svaret bærer Framed-IP-Address og gatewayen bruker den verdien på sesjonen. Gatewayen eier den når en administrator tilordner kontoen til en statisk adresse i poolen. Klienten eier ingenting, selv når adapteren viser en manuell adresse, fordi serveren tildeler den indre adressen under forhandlingen, og en lokal innstilling betyr bare noe når serveren ikke sender noen. Alle tre ser identiske ut på en fungerende tilkobling, og derfor dukker konflikter opp sent. Forskjellen vises ved gjenoppkobling, på en annen enhet og etter en policyendring.

To eiere er den konfigurasjonen som ryker. Et RADIUS-svar som tildeler 172.28.4.77 mens gatewayen har en statisk tilordning til 172.28.4.90, gir den verdien som leverandørens kode sjekker først, og taperen forkastes uten en logglinje. Samme konto på en annen enhet mottar da en duplikatadresse, og symptomet leses som en rutingsfeil snarere enn en tildelingskonflikt. Avgjør eieren før du legger til den andre mekanismen.

Klientalternativet er bare verdt å nevne for å kunne utelukke det. En manuell adapteradresse er en preferanse operativsystemet kan vise, ikke en reservasjon, og den kan ikke hindre en annen sesjon i å få samme adresse.

Hva RADIUS-svaret kan og ikke kan love

RFC 2865definerer Framed-IP-Address som IPv4-adressen som skal konfigureres for brukeren, og den hører i Access-Accept. Samme attributt i Access-Request er bare et hint serveren kan ignorere, og det betyr noe når en klient eller gateway tilbyr en foretrukket adresse. Ingenting i protokollen tvinger gatewayen til å ære svaret, fordi nettverkstilgangsserveren er komponenten som bruker det på sesjonen.

Støtte er et produktspørsmål og ikke et protokollspørsmål. Noen gatewayer bruker innrammede adresser som standard, andre trenger en bryter på gruppenivå slått på før de gjør det, og atter andre godtar attributtet og bruker det aldri for fjernaksesesjoner. Det siste tilfellet er det farlige, fordi regnskapsposten kan vise svaret mens klienten mottar en pooladresse. Bekreft atferden på den nøyaktige gatewaymodellen og fastvaren du kjører, ikke i dokumentasjonen til et søsterprodukt.

Et svar gatewayen ignorerer ser nøyaktig ut som et svar som aldri ble sendt. Å lese Access-Accept og sesjonens adresse side om side er den eneste måten å skille de to tilfellene.

Reserver adressen i poolen du allerede ruter

Velg den faste adressen fra poolens undernett som gatewayen allerede ruter og som brannmuren allerede stoler på. En adresse utenfor det området gjør en policyendring til et rutingsprosjekt, og VPN kommer opp mens ingenting bak den kan svare. Hvis det finnes tilgangsregler per adresse, legg den faste adressen til dem i samme endring.

Bestem hva en andre samtidig sesjon skal gjøre. Å tildele én adresse to ganger er ikke enhetsadministrasjon, og kollisjonen som oppstår vises som periodisk tilkobling for begge sesjonene. Utsted enten forskjellige identiteter per enhet, forskjellige tildelinger, eller håndhev samtidighet med en støttet sjekk, som for eksempel Simultaneous-Use, i stedet for å håpe at klienten aldri kobler til på nytt før den gamle sesjonen utløper.

Returruter fortjener samme oppmerksomhet som tildelingen. Gatewayen trenger en rute til poolen, de interne ruterne trenger en rute tilbake til gatewayen, og den faste adressen arver begge. Én klient som virker mens alle andre feiler, betyr vanligvis at poolruten finnes, men at vertsruten for den reserverte adressen ikke gjør det.

Test svaret før du stoler på reservasjonen

Test AAA-siden og sesjonssiden hver for seg, fordi de feiler av forskjellige grunner. En lokal radtest viser hva serveren returnerer for kontoen uten å involvere gatewayen, og oppføringen i brukerfilen viser hva serveren skal matche. Koble deretter klienten til på nytt og sammenlign adressen den fikk 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

En Access-Accept uten attributtet betyr at serveren ikke matchet oppføringen, eller at attributtet ikke ble brukt på den brukeren. En Access-Accept med attributtet og en klient som fortsatt mottar en pooladresse, betyr at gatewayen ignorerte det. En Access-Reject sender deg tilbake til påloggingsinformasjonen eller gruppepolicyen, og ingen av disse utfallene bør feilsøkes ved å redigere klientadapteren.

Gjenta sjekken etter en gjenoppkobling og etter en annen pålogging fra en annen enhet. En reservasjon som bare holder for den første sesjonen, er en poolkonflikt som venter på å skje, og det er billigere å finne den nå enn under en revisjon.

Velg én eier og skriv den ned

Hvis gatewayen bruker innrammede adresser pålitelig, la RADIUS eie tildelingen og fjern enhver statisk tilordning for samme konto. Hvis ikke, la gatewayen eie den og fjern attributtet fra svaret, slik at de to kildene ikke kan være uenige. Å beholde begge fordi hver av dem nesten virker, garanterer en fremtidig sesjon med feil adresse og uten åpenbar årsak.

Skriv den valgte eieren, den reserverte adressen og poolen den kom fra i kontoposten. Den neste personen som legger til en enhet, kan da se om adressen er en AAA-policy eller en gatewaytilordning før vedkommende endrer noen av dem.