Fiksa VPN-IP: Framed-IP-Address en RADIUS aŭ rezervo en la baseno

Tri lokoj povas teni fiksan internan adreson por VPN-kliento, kaj nur unu el ili devus posedi ĝin. RADIUS povas redoni la adreson en Access-Accept, la pordego povas teni statikan mapadon por la konto, kaj la klienta adaptilo povas esti agordita permane. La unuaj du estas politiko kaj la tria estas loka konjekto, kiun la pordego rajtas ignori aŭ superskribi. Elekti inter la unuaj du estas la vera decido, kaj ĝi dependas de tio, kion la ret-alirapa servilo efektive implementas.

Tri lokoj, kie fiksa adreso povas loĝi

RADIUS posedas la adreson kiam la respondo portas Framed-IP-Address kaj la pordego aplikas tiun valoron al la sesio. La pordego posedas ĝin kiam administranto mapas la konton al statika adreso ene de la baseno. La kliento posedas nenion, eĉ kiam ĝia adaptilo montras permanan adreson, ĉar la servilo asignas la internan adreson dum la intertraktado kaj loka agordo gravas nur kiam la servilo sendas nenion. Ĉiuj tri aspektas idente ĉe funkcianta konekto, kaj tial konfliktoj aperas malfrue. La diferenco montriĝas ĉe rekonekto, ĉe dua aparato kaj post politika ŝanĝo.

Du posedantoj estas la agordo, kiu rompiĝas. RADIUS-respondo asignanta 172.28.4.77 dum la pordego tenas statikan mapadon por 172.28.4.90 donas tiun valoron, kiun la kodo de la vendisto kontrolas unue, kaj la perdanto estas forĵetata sen loglinio. La sama konto ĉe dua aparato tiam ricevas duoblan adreson, kaj la simptomo legeblas kiel vojiga paneo anstataŭ asignkonflikto. Difinu la posedanton antaŭ ol aldoni la duan mekanismon.

La klientflanka opcio indas esti nomata nur por esti ekskludita. Permanenta adaptila adreso estas prefero, kiun la operaciumo povas prezenti, ne rezervo, kaj ĝi ne povas malhelpi alian sesion ricevi la saman adreson.

Kion la RADIUS-respondo povas promesi kaj kion ne

RFC 2865difinas Framed-IP-Address kiel la IPv4-adreson agordotan por la uzanto, kaj ĝi apartenas al Access-Accept. La sama atributo en Access-Request estas nur aludo, kiun la servilo rajtas ignori, kio gravas kiam kliento aŭ pordego proponas preferatan adreson. Nenio en la protokolo devigas la pordegon respekti la respondon, ĉar la ret-alirapa servilo estas la komponanto, kiu aplikas ĝin al la sesio.

Subteno estas produkta demando, ne protokola. Kelkaj pordegoj aplikas kadritajn adresojn defaŭlte, kelkaj bezonas ŝaltilon je grupa nivelo antaŭ ol ili tion faros, kaj kelkaj akceptas la atributon kaj neniam uzas ĝin por fora aliro. La lasta kazo estas la danĝera, ĉar la konta registro povas montri la respondon dum la kliento ricevas basenan adreson. Konfirmu la konduton ĉe la ekzakta pordega modelo kaj firmaro, kiun vi uzas, ne en la dokumentaro de frata produkto.

Respondo, kiun la pordego ignoras, aspektas ekzakte kiel respondo, kiu neniam estis sendita. Legi la Access-Accept kaj la sesian adreson unu apud la alia estas la sola maniero apartigi la du kazojn.

Rezervu la adreson ene de la baseno, kiun vi jam vojigas

Elektu la fiksan adreson el la basena subreto, kiun la pordego jam vojigas kaj kiun la fajroŝirmilo jam fidas. Adreso ekster tiu gamo transformas politikan ŝanĝon en vojigan projekton, kaj la VPN ekfunkcios dum nenio malantaŭ ĝi povos respondi. Se ekzistas alirreguloj laŭ adreso, aldonu la fiksan adreson al ili en la sama ŝanĝo.

Decidu, kion dua samtempa sesio devus fari. Asigni unu adreson dufoje ne estas aparata administrado, kaj la rezulta kolizio aperas kiel intermita konekteco por ambaŭ sesioj. Aŭ eldonu apartajn identecojn por ĉiu aparato, aŭ apartajn asignojn, aŭ devigu samtempecon per subtenata kontrolo, kiel ekzemple Simultaneous-Use, anstataŭ esperi, ke la kliento neniam rekonektiĝos antaŭ ol la malnova sesio eksvalidiĝos.

Revenaj vojoj meritas la saman atenton kiel la asigno. La pordego bezonas vojon al la baseno, la internaj enkursigiloj bezonas vojon reen al la pordego, kaj la fiksa adreso heredas ambaŭ. Unu kliento, kiu funkcias dum ĉiuj aliaj malsukcesas, kutime signifas, ke la basena vojo ekzistas sed la gastiga vojo por la rezervita adreso ne.

Testu la respondon antaŭ ol fidi la rezervon

Testu la AAA-flankon kaj la sesian flankon aparte, ĉar ili malsukcesas pro malsamaj kaŭzoj. Loka radtest montras, kion la servilo redonas por la konto sen impliki la pordegon, kaj la ero en la uzula dosiero montras, kun kio la servilo devus kongrui. Poste rekonektu la klienton kaj komparu la ricevitan adreson kun la atributo en la respondo.

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 sen la atributo signifas, ke la servilo ne kongruigis la eron aŭ ke la atributo ne estis aplikita al tiu uzanto. Access-Accept kun la atributo kaj kliento, kiu ankoraŭ ricevas basenan adreson, signifas, ke la pordego ignoris ĝin. Access-Reject resendas vin al la legitimiloj aŭ al la grupa politiko, kaj neniu el tiuj rezultoj devus esti sencimigata per redaktado de la klienta adaptilo.

Ripetu la kontrolon post rekonekto kaj post dua ensaluto el alia aparato. Rezervo, kiu teniĝas nur por la unua sesio, estas basena konflikto atendanta okazi, kaj estas pli malmultekoste trovi ĝin nun ol dum revizio.

Elektu unu posedanton kaj skribu ĝin

Se la pordego fidinde aplikas kadritajn adresojn, lasu RADIUS posedi la asigon kaj forigu ĉian statikan mapadon por la sama konto. Se ne, lasu la pordegon posedi ĝin kaj forigu la atributon el la respondo, por ke la du fontoj ne povu malkonsenti. Reteni ambaŭ ĉar ĉiu preskaŭ funkcias garantias estontan sesion kun la malĝusta adreso kaj sen evidenta kaŭzo.

Skribu la elektitan posedanton, la rezervitan adreson kaj la basenon, el kiu ĝi venas, en la kontan registron. La sekva persono, kiu aldonos aparaton, povos vidi, ĉu la adreso estas AAA-politiko aŭ pordega mapado, antaŭ ol ŝanĝi iun el ili.