Fiksni VPN IP: Framed-IP-Address v RADIUS-u ali rezervacija v bazenu

Tri mesta lahko hranijo fiksni notranji naslov za odjemalca VPN, in samo eno od njih naj bi ga posedovalo. RADIUS lahko naslov vrne v Access-Accept, prehod lahko vodi statično preslikavo za račun, odjemalčev vmesnik pa je mogoče nastaviti ročno. Prva dva sta politika, tretji pa je lokalna domneva, ki jo prehod lahko prosto prezre ali prepiše. Izbira med prvima dvema je prava odločitev in je odvisna od tega, kaj strežnik za dostop do omrežja v resnici izvaja.

Tri mesta, kjer lahko živi fiksni naslov

RADIUS poseduje naslov, ko odgovor nosi Framed-IP-Address in prehod to vrednost uporabi za sejo. Prehod ga poseduje, ko skrbnik preslika račun na statični naslov v bazenu. Odjemalec ne poseduje ničesar, tudi ko njegov vmesnik prikazuje ročni naslov, ker strežnik notranji naslov dodeli med pogajanji, lokalna nastavitev pa je pomembna le, kadar strežnik ne pošlje nobenega. Vsi trije so na delujoči povezavi videti enako, zato se konflikti pokažejo pozno. Razlika se vidi pri ponovnem povezovanju, na drugi napravi in po spremembi politike.

Dva lastnika sta konfiguracija, ki se zlomi. Odgovor RADIUS-a dodeli 172.28.4.77, medtem ko prehod hrani statično preslikavo za 172.28.4.90, zato se uporabi vrednost, ki jo koda proizvajalca preveri prva, poraženec pa se zavrže brez vrstice v dnevniku. Isti račun na drugi napravi nato prejme podvojen naslov in simptom se bere kot napaka pri usmerjanju, ne kot konflikt pri dodeljevanju. Določite lastnika, preden dodate drugi mehanizem.

Možnost na strani odjemalca je vredna omembe le zato, da jo je mogoče izključiti. Ročni naslov vmesnika je nastavitev, ki jo operacijski sistem lahko prikaže, ne rezervacija, in ne more preprečiti, da bi druga seja prejela isti naslov.

Kaj lahko odgovor RADIUS-a obljubi in česa ne

RFC 2865opredeli Framed-IP-Address kot naslov IPv4, ki ga je treba nastaviti za uporabnika, in spada v Access-Accept. Isti atribut v Access-Request je le namig, ki ga strežnik lahko prezre, kar je pomembno, ko odjemalec ali prehod ponudi prednostni naslov. Nič v protokolu ne sili prehoda, da odgovor upošteva, ker je strežnik za dostop do omrežja tisti gradnik, ki ga uporabi za sejo.

Podpora je vprašanje izdelka in ne protokola. Nekateri prehodi uokvirjene naslove uporabijo privzeto, drugi potrebujejo vklopljeno stikalo na ravni skupine, tretji pa atribut sprejmejo in ga nikoli ne uporabijo za seje oddaljenega dostopa. Zadnji primer je nevaren, ker lahko obračunski zapis prikazuje odgovor, medtem ko odjemalec prejme naslov iz bazena. Potrdite vedenje na točnem modelu prehoda in vdelani programski opremi, ki jo poganjate, ne v dokumentaciji sestrskega izdelka.

Odgovor, ki ga prehod prezre, je videti natanko tako kot odgovor, ki ni bil nikoli poslan. Branje Access-Accept in naslova seje drug ob drugem je edini način za ločevanje teh dveh primerov.

Rezervirajte naslov v bazenu, ki ga že usmerjate

Izberite fiksni naslov iz podomrežja bazena, ki ga prehod že usmerja in mu požarni zid že zaupa. Naslov zunaj tega obsega spremeni spremembo politike v projekt usmerjanja, VPN pa se dvigne, medtem ko nič za njim ne more odgovoriti. Če obstajajo pravila dostopa po naslovu, dodajte fiksni naslov mednje v isti spremembi.

Odločite, kaj naj stori druga sočasna seja. Dodelitev enega naslova dvakrat ni upravljanje naprav in nastali trk se pokaže kot občasna povezljivost za obe seji. Ali izdajte različne identitete na napravo, ali različne dodelitve, ali vsilite sočasnost s podprtim preverjanjem, kot je Simultaneous-Use, namesto da bi upali, da se odjemalec ne bo nikoli znova povezal pred potekom stare seje.

Povratne poti si zaslužijo enako pozornost kot dodelitev. Prehod potrebuje pot v bazen, notranji usmerjevalniki pot nazaj do prehoda, fiksni naslov pa podeduje obe. En odjemalec, ki deluje, medtem ko vsi drugi odpovedo, običajno pomeni, da pot bazena obstaja, pot do gostitelja za rezervirani naslov pa ne.

Preizkusite odgovor, preden zaupate rezervaciji

Preizkusite stran AAA in stran seje ločeno, ker odpovedo iz različnih razlogov. Lokalni radtest pokaže, kaj strežnik vrne za račun, ne da bi vključil prehod, zapis v datoteki uporabnikov pa pokaže, s čim naj bi se strežnik ujemal. Nato znova povežite odjemalca in primerjajte prejeti naslov z atributom v odgovoru.

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 brez atributa pomeni, da strežnik ni ujemal zapisa ali da atribut ni bil uporabljen za tega uporabnika. Access-Accept z atributom in odjemalec, ki še vedno prejema naslov iz bazena, pomeni, da ga je prehod prezrl. Access-Reject vas vrne k poverilnicam ali skupinski politiki in nobenega od teh izidov ne bi smeli odpravljati z urejanjem odjemalčevega vmesnika.

Ponovite preverjanje po ponovnem povezovanju in po drugi prijavi z druge naprave. Rezervacija, ki zdrži le prvo sejo, je konflikt v bazenu, ki čaka, da se zgodi, in ceneje ga je najti zdaj kot med revizijo.

Izberite enega lastnika in ga zapišite

Če prehod zanesljivo uporablja uokvirjene naslove, prepustite dodelitev RADIUS-u in odstranite vsako statično preslikavo za isti račun. Če ne, prepustite jo prehodu in odstranite atribut iz odgovora, da se oba vira ne moreta razhajati. Ohranjanje obeh, ker vsak skoraj deluje, zagotavlja prihodnjo sejo z napačnim naslovom in brez očitnega vzroka.

Zapišite izbranega lastnika, rezervirani naslov in bazen, iz katerega prihaja, v zapis računa. Naslednja oseba, ki doda napravo, bo lahko videla, ali je naslov politika AAA ali preslikava na prehodu, preden katero koli spremeni.