RADIUS kan svara med en adress för en viss användare; huruvida tunneln verkligen får den beror på gatewayen. Det är i gapet mellan returnerat och tillämpat som de flesta planer på en stabil adress misslyckas. Ett attribut i ett testsvar bevisar att servern kan skicka det, inte att fjärråtkomsttjänsten tillämpar det. Sekvensen nedan kontrollerar båda halvorna innan adressen hamnar i brandväggsreglerna.

Bestäm vilket lager som äger adressen

Fjärråtkomstgatewayer har vanligtvis en lokal pool, och många kan också ta emot en adress från autentiseringssvaret. Vilken som vinner beror på plattformen, protokollet och tjänstens konfiguration, så läs prioritetsregeln för den exakta version som används. Där den lokala poolen har prioritet är attributet bara dekoration och klienten landar ändå på en slumpmässig adress. Skriv ner beslutet, inklusive om ett returnerat värde måste ligga inom poolens intervall eller får hamna utanför det.

RFC 2865 definierar Framed-IP-Address som den adress som ska konfigureras för användaren, och säger ingenting om en viss gateways vilja att respektera den. Leverantörens dokumentation är auktoriteten för prioritet, inte attributets definition.

Skicka en testförfrågan och läs svaret

Testa först servern separat, så att ett saknat attribut inte misstas för ett gatewayproblem. radtest skickar en Access-Request och skriver ut de attribut som kommer tillbaka.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Leta efter Framed-IP-Address i Access-Accept och bekräfta att värdet är det avsedda och inte en pooldress från en reservregel. När attributet saknas matchar inte användarposten eller auktorisationspolicyn, och gatewayjustering kan inte leverera det som servern aldrig skickade. Upprepa förfrågan medan servern körs i felsökningsläge om svaret är svårt att spåra till en specifik regel. Håll den delade hemligheten utanför skalkommandohistoriken och ärendena, eftersom platshållaren ovan inte är någon inloggningsuppgift.

Bekräfta att gatewayen respekterade värdet

Ett korrekt svar är bara halva kontraktet. Adressen som visas på tunnelgränssnittet är den observation som räknas, och den läses på klienten i stället för att härledas från gatewaykonfigurationen.

ip -4 addr show tun0

Jämför den adressen med attributet från Access-Accept. En avvikelse betyder att gatewayen ignorerade eller skrev om värdet, vilket öppnar prioritetsfrågan från första avsnittet igen. Anslut en gång till, eftersom en reservering som bara fungerar vid första försöket oftast pekar på en inaktuell session eller en lease som den tidigare anslutningen fortfarande håller. Anteckna gatewayversionen och protokollet bredvid resultatet, så att nästa person kan avgöra om beteendet är versionsberoende.

Planera för samtidighet och återkallning

Ett användarnamn på två enheter kan inte mappas till en adress om inte gatewayen skiljer sessionerna åt med något utöver inloggningen. Bestäm om mappningen tillhör en person, en registrerad enhet eller en certifikatidentitet, och gör det valet uttryckligt i principförrådet. Testa en andra samtidig klient och jämför båda tilldelade adresserna, eftersom en kollision här dyker upp senare som ett routningsfel. Samma omsorg hör hemma i återkallningsplanen, eftersom en adress som tilldelas på nytt medan gamla brandväggsregler fortfarande refererar till den blir en auktoriseringsbugg.

Stabil adressering förenklar regler och loggar, men bevisar aldrig vem som skapade ett paket. Autentisering och destinationsauktorisation spelar fortfarande roll när adressen senare flyttar till en annan session.

Relaterade artiklar