Fiksuotas VPN IP: RADIUS Framed-IP-Address ar rezervacija telkinyje

Trys vietos gali laikyti fiksuotą vidinį adresą VPN klientui, ir tik viena iš jų turėtų jį valdyti. RADIUS gali grąžinti adresą Access-Accept atsakyme, tinklų sietuva gali laikyti statinį susiejimą paskyrai, o kliento adapterį galima nustatyti rankiniu būdu. Pirmosios dvi yra politika, o trečioji – vietinė prielaida, kurią sietuva gali laisvai ignoruoti arba perrašyti. Pasirinkimas tarp pirmųjų dviejų yra tikrasis sprendimas, ir jis priklauso nuo to, ką tinklo prieigos serveris iš tikrųjų įgyvendina.

Trys vietos, kur gali būti fiksuotas adresas

RADIUS valdo adresą, kai atsakyme yra Framed-IP-Address ir sietuva pritaiko tą reikšmę sesijai. Sietuva jį valdo, kai administratorius susieja paskyrą su statiniu adresu telkinyje. Klientas nieko nevaldo, net kai jo adapteris rodo rankiniu būdu įvestą adresą, nes serveris vidinį adresą priskiria derybų metu, o vietinis nustatymas svarbus tik tada, kai serveris nieko nesiunčia. Visi trys atrodo vienodai veikiančioje jungtyje, todėl konfliktai iškyla vėlai. Skirtumas matomas prisijungiant iš naujo, antrame įrenginyje ir po politikos pakeitimo.

Du savininkai – tai konfigūracija, kuri lūžta. RADIUS atsakymas priskiria 172.28.4.77, o sietuva laiko statinį susiejimą 172.28.4.90, todėl gaunama reikšmė, kurią gamintojo kodas patikrina pirmiausia, o pralaimėjusioji atmetama be žurnalo eilutės. Ta pati paskyra antrame įrenginyje tada gauna pasikartojantį adresą, ir simptomas skaitomas kaip maršrutizavimo gedimas, o ne priskyrimo konfliktas. Nuspręskite savininką prieš pridėdami antrą mechanizmą.

Kliento pusės variantą verta įvardyti tik tam, kad jį būtų galima atmesti. Rankinis adapterio adresas yra nuostata, kurią operacinė sistema gali parodyti, o ne rezervacija, ir ji negali sutrukdyti kitai sesijai gauti to paties adreso.

Ką RADIUS atsakymas gali pažadėti, o ko ne

RFC 2865apibrėžia Framed-IP-Address kaip IPv4 adresą, kurį reikia sukonfigūruoti vartotojui, ir jis priklauso Access-Accept. Tas pats atributas Access-Request yra tik užuomina, kurią serveris gali ignoruoti, ir tai svarbu, kai klientas ar sietuva siūlo pageidaujamą adresą. Niekas protokole neverčia sietuvos gerbti atsakymo, nes tinklo prieigos serveris yra komponentas, kuris jį pritaiko sesijai.

Palaikymas yra produkto, o ne protokolo klausimas. Kai kurios sietuvos taiko įrėmintus adresus pagal nutylėjimą, kitoms reikia įjungti grupės lygio jungiklį, o dar kitos priima atributą ir niekada nenaudoja jo nuotolinės prieigos sesijoms. Pastarasis atvejis pavojingas, nes apskaitos įrašas gali rodyti atsakymą, kol klientas gauna telkinio adresą. Patvirtinkite elgseną tiksliai toje sietuvos modelyje ir programinėje įrangoje, kurią naudojate, o ne seserinio produkto dokumentacijoje.

Atsakymas, kurį sietuva ignoruoja, atrodo lygiai taip pat kaip atsakymas, kuris niekada nebuvo išsiųstas. Access-Accept ir sesijos adreso skaitymas greta yra vienintelis būdas atskirti šiuos du atvejus.

Rezervuokite adresą telkinyje, kurį jau maršrutizuojate

Pasirinkite fiksuotą adresą iš telkinio potinklės, kurią sietuva jau maršrutizuoja ir kuria ugniasienė jau pasitiki. Adresas už šio diapazono ribų paverčia politikos pakeitimą maršrutizavimo projektu, ir VPN veiks, tačiau niekas už jo negalės atsakyti. Jei yra prieigos taisyklės pagal adresą, tame pačiame pakeitime pridėkite fiksuotą adresą prie jų.

Nuspręskite, ką turėtų daryti antroji vienalaikė sesija. Vieno adreso priskyrimas du kartus nėra įrenginių valdymas, ir atsiradęs susidūrimas pasireiškia kaip trumpalaikis ryšys abiem sesijoms. Arba išduokite skirtingas tapatybes kiekvienam įrenginiui, arba skirtingus priskyrimus, arba užtikrinkite vienalaikiškumą palaikoma patikra, pavyzdžiui Simultaneous-Use, o ne tikėdamiesi, kad klientas niekada neprisijungs iš naujo prieš pasibaigiant senajai sesijai.

Grįžimo maršrutai nusipelno tokio pat dėmesio kaip priskyrimas. Sietuvai reikia maršruto į telkinį, vidiniams maršrutizatoriams reikia maršruto atgal į sietuvą, o fiksuotas adresas paveldi abu. Vienas veikiantis klientas, kai visi kiti nepavyksta, paprastai reiškia, kad telkinio maršrutas yra, bet rezervuoto adreso pagrindinio kompiuterio maršruto nėra.

Išbandykite atsakymą prieš pasitikėdami rezervacija

Išbandykite AAA pusę ir sesijos pusę atskirai, nes jos nepavyksta dėl skirtingų priežasčių. Vietinis radtest parodo, ką serveris grąžina paskyrai neįtraukdamas sietuvos, o vartotojų failo įrašas parodo, su kuo serveris turėtų sutapti. Tada prijunkite klientą iš naujo ir palyginkite gautą adresą su atsakymo atributu.

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

Access-Accept be atributo reiškia, kad serveris nesutapo įrašo arba atributas nebuvo pritaikytas tam vartotojui. Access-Accept su atributu ir klientas, kuris vis dar gauna telkinio adresą, reiškia, kad sietuva jį ignoravo. Access-Reject grąžina jus prie prisijungimo duomenų arba grupių politikos, ir nė vienas iš šių rezultatų neturėtų būti derinamas redaguojant kliento adapterį.

Pakartokite patikrą po prisijungimo iš naujo ir po antro prisijungimo iš kito įrenginio. Rezervacija, kuri išlieka tik pirmai sesijai, yra telkinio konfliktas, kuris laukia įvyksiantis, ir pigiau jį rasti dabar nei audito metu.

Pasirinkite vieną savininką ir užrašykite jį

Jei sietuva patikimai taiko įrėmintus adresus, leiskite RADIUS valdyti priskyrimą ir pašalinkite bet kokį statinį susiejimą tai pačiai paskyrai. Jei ne, leiskite sietuvai jį valdyti ir pašalinkite atributą iš atsakymo, kad du šaltiniai negalėtų nesutapti. Abiejų laikymas dėl to, kad kiekvienas beveik veikia, garantuoja būsimą sesiją su neteisingu adresu ir be akivaizdžios priežasties.

Įrašykite pasirinktą savininką, rezervuotą adresą ir telkinį, iš kurio jis atėjo, į paskyros įrašą. Kitas žmogus, pridedantis įrenginį, galės pamatyti, ar adresas yra AAA politika, ar sietuvos susiejimas, prieš keisdamas bet kurį iš jų.