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

Tre ställen kan hålla en fast intern adress för en VPN-klient, och bara ett av dem bör äga den. RADIUS kan returnera adressen i en Access-Accept, gatewayen kan hålla en statisk mappning för kontot, och klientadaptern kan ställas in manuellt. De två första är policy och det tredje är en lokal gissning som gatewayen fritt kan ignorera eller skriva över. Valet mellan de två första är det egentliga beslutet, och det beror på vad nätverksåtkomstservern faktiskt implementerar.

Tre ställen där en fast adress kan bo

RADIUS äger adressen när svaret bär Framed-IP-Address och gatewayen tillämpar värdet på sessionen. Gatewayen äger den när en administratör mappar kontot till en statisk adress i poolen. Klienten äger ingenting, även när adaptern visar en manuell adress, eftersom servern tilldelar den interna adressen under förhandlingen och en lokal inställning bara spelar roll när servern inte skickar någon. Alla tre ser likadana ut på en fungerande anslutning, vilket är varför konflikter dyker upp sent. Skillnaden syns vid återanslutning, på en andra enhet och efter en policyändring.

Två ägare är konfigurationen som går sönder. Ett RADIUS-svar som tilldelar 172.28.4.77 medan gatewayen har en statisk mappning för 172.28.4.90 ger det värde som leverantörens kod kontrollerar först, och förloraren slängs utan en logglinje. Samma konto på en andra enhet får då en dubbeladress, och symptomet läses som ett routingfel snarare än en tilldelningskonflikt. Bestäm ägaren innan du lägger till den andra mekanismen.

Klientalternativet är bara värt att nämna för att kunna utesluta det. En manuell adapteradress är en preferens som operativsystemet kan visa, inte en reservation, och den kan inte hindra en annan session från att få samma adress.

Vad RADIUS-svaret kan och inte kan lova

RFC 2865definierar Framed-IP-Address som den IPv4-adress som ska konfigureras för användaren, och den hör hemma i Access-Accept. Samma attribut i Access-Request är bara en antydan som servern kan ignorera, vilket spelar roll när en klient eller gateway erbjuder en föredragen adress. Ingenting i protokollet tvingar gatewayen att följa svaret, eftersom nätverksåtkomstservern är den komponent som tillämpar det på sessionen.

Stöd är en produktfråga och inte en protokollfråga. Vissa gatewayer tillämpar inramade adresser som standard, andra behöver en brytare på gruppnivå påslagen innan de gör det, och åter andra accepterar attributet och använder det aldrig för fjärråtkomstsessioner. Det sista fallet är det farliga, eftersom redovisningsposten kan visa svaret medan klienten får en pooldress. Bekräfta beteendet på den exakta gatewaymodell och firmware som du kör, inte i dokumentationen för en systerprodukt.

Ett svar som gatewayen ignorerar ser exakt ut som ett svar som aldrig skickades. Att läsa Access-Accept och sessionens adress sida vid sida är det enda sättet att skilja de två fallen.

Reservera adressen i poolen du redan routar

Välj den fasta adressen från poolens undernät som gatewayen redan routar och som brandväggen redan litar på. En adress utanför det intervallet gör en policyändring till ett routingprojekt, och VPN:en kommer upp medan ingenting bakom den kan svara. Finns det åtkomstregler per adress, lägg till den fasta adressen i dem i samma ändring.

Bestäm vad en andra samtidig session ska göra. Att tilldela en adress två gånger är inte enhetshantering, och kollisionen som uppstår visas som intermittent anslutning för båda sessionerna. Utfärda antingen olika identiteter per enhet, olika tilldelningar, eller genomdriv samtidighet med en kontroll som stöds, till exempel Simultaneous-Use, i stället för att hoppas att klienten aldrig återansluter innan den gamla sessionen löper ut.

Returvägar förtjänar samma uppmärksamhet som tilldelningen. Gatewayen behöver en väg till poolen, de interna routrarna behöver en väg tillbaka till gatewayen, och den fasta adressen ärver båda. En enda klient som fungerar medan alla andra misslyckas betyder oftast att poolvägen finns men att värdvägen för den reserverade adressen inte gör det.

Testa svaret innan du litar på reservationen

Testa AAA-sidan och sessionssidan var för sig, eftersom de misslyckas av olika skäl. En lokal radtest visar vad servern returnerar för kontot utan att involvera gatewayen, och posten i användarfilen visar vad servern ska matcha. Återanslut sedan klienten och jämför adressen den fick med attributet 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 utan attributet betyder att servern inte matchade posten eller att attributet inte tillämpades på den användaren. En Access-Accept med attributet och en klient som fortfarande får en pooldress betyder att gatewayen ignorerade det. En Access-Reject skickar dig tillbaka till inloggningsuppgifterna eller grupprincipen, och inget av dessa utfall bör felsökas genom att redigera klientadaptern.

Upprepa kontrollen efter en återanslutning och efter en andra inloggning från en annan enhet. En reservation som bara håller för den första sessionen är en poolkonflikt som väntar på att inträffa, och det är billigare att hitta den nu än under en revision.

Välj en ägare och skriv ner den

Om gatewayen tillämpar inramade adresser pålitligt, låt RADIUS äga tilldelningen och ta bort all statisk mappning för samma konto. Om inte, låt gatewayen äga den och ta bort attributet från svaret, så att de två källorna inte kan vara oense. Att behålla båda eftersom var och en nästan fungerar garanterar en framtida session med fel adress och utan uppenbar orsak.

Skriv den valda ägaren, den reserverade adressen och poolen den kom från i kontoposten. Nästa person som lägger till en enhet kan då se om adressen är en AAA-policy eller en gatewaymappning innan hen ändrar någon av dem.