Fiksēta VPN IP: RADIUS Framed-IP-Address vai rezervācija baseinā

Trīs vietas var glabāt fiksētu iekšējo adresi VPN klientam, un tikai vienai no tām tā būtu jāpārvalda. RADIUS var atgriezt adresi Access-Accept atbildē, vārteja var glabāt statisku kartējumu kontam, un klienta adapteri var iestatīt manuāli. Pirmās divas ir politika, bet trešā ir lokāls pieņēmums, ko vārteja drīkst ignorēt vai pārrakstīt. Izvēle starp pirmajām divām ir īstais lēmums, un tas ir atkarīgs no tā, ko tīkla piekļuves serveris patiešām ievieš.

Trīs vietas, kur var būt fiksēta adrese

RADIUS pārvalda adresi, kad atbilde satur Framed-IP-Address un vārteja piemēro šo vērtību sesijai. Vārteja to pārvalda, kad administrators kartē kontu uz statisku adresi baseinā. Klients nepārvalda neko, pat ja tā adapteris rāda manuālu adresi, jo serveris iekšējo adresi piešķir sarunu laikā, un lokāls iestatījums ir svarīgs tikai tad, kad serveris neko nesūta. Visi trīs izskatās vienādi uz strādājoša savienojuma, tāpēc konflikti parādās vēlu. Atšķirība redzama atkārtoti pieslēdzoties, otrajā ierīcē un pēc politikas maiņas.

Divi īpašnieki ir tā konfigurācija, kas salūzt. RADIUS atbilde piešķir 172.28.4.77, kamēr vārteja glabā statisku kartējumu 172.28.4.90, tāpēc tiek iegūta vērtība, ko ražotāja kods pārbauda pirmais, un zaudētājs tiek izmests bez žurnāla rindas. Tas pats konts otrajā ierīcē tad saņem dublētu adresi, un simptoms tiek lasīts kā maršrutēšanas kļūda, nevis piešķiršanas konflikts. Izlemiet īpašnieku pirms otrā mehānisma pievienošanas.

Klienta puses opciju ir vērts nosaukt tikai tāpēc, lai to izslēgtu. Manuāla adaptera adrese ir izvēle, ko operētājsistēma var parādīt, nevis rezervācija, un tā nevar liegt citai sesijai saņemt to pašu adresi.

Ko RADIUS atbilde var apsolīt un ko ne

RFC 2865definē Framed-IP-Address kā IPv4 adresi, kas lietotājam jākonfigurē, un tā pieder Access-Accept. Tas pats atribūts Access-Request ir tikai mājiens, ko serveris var ignorēt, un tas ir svarīgi, kad klients vai vārteja piedāvā vēlamo adresi. Nekas protokolā neliek vārtejai ievērot atbildi, jo tīkla piekļuves serveris ir komponente, kas to piemēro sesijai.

Atbalsts ir produkta, nevis protokola jautājums. Dažas vārtejas ietvertās adreses piemēro pēc noklusējuma, citām pirms tam jāieslēdz grupas līmeņa slēdzis, bet vēl citas pieņem atribūtu un nekad neizmanto to attālinātās piekļuves sesijām. Pēdējais gadījums ir bīstamais, jo uzskaites ieraksts var rādīt atbildi, kamēr klients saņem baseina adresi. Apstipriniet uzvedību tieši tajā vārtejas modelī un programmaparatūrā, ko izmantojat, nevis māsas produkta dokumentācijā.

Atbilde, ko vārteja ignorē, izskatās tieši tāpat kā atbilde, kas nekad netika nosūtīta. Access-Accept un sesijas adreses lasīšana līdzās ir vienīgais veids, kā atšķirt šos divus gadījumus.

Rezervējiet adresi baseinā, kuru jau maršrutējat

Izvēlieties fiksēto adresi no baseina apakštīkla, kuru vārteja jau maršrutē un kuram ugunsmūris jau uzticas. Adrese ārpus šī diapazona pārvērš politikas maiņu maršrutēšanas projektā, un VPN darbosies, kamēr nekas aiz tā nevarēs atbildēt. Ja pastāv piekļuves noteikumi pēc adreses, tajā pašā izmaiņā pievienojiet fiksēto adresi tiem.

Izlemiet, ko darīt otrajai vienlaicīgajai sesijai. Vienas adreses piešķiršana divreiz nav ierīču pārvaldība, un radušās sadursmes izpaužas kā pārtraukts savienojums abām sesijām. Vai nu izsniedziet atšķirīgas identitātes katrai ierīcei, atšķirīgus piešķīrumus, vai arī panāciet vienlaicīgumu ar atbalstītu pārbaudi, piemēram Simultaneous-Use, tā vietā cerot, ka klients nekad neatkārtoti pieslēgsies pirms vecās sesijas beigām.

Atgriešanās maršruti ir pelnījuši tādu pašu uzmanību kā piešķīrums. Vārtejai vajadzīgs maršruts uz baseinu, iekšējiem maršrutētājiem vajadzīgs maršruts atpakaļ uz vārteju, un fiksētā adrese manto abus. Viena klienta darbība, kamēr visi pārējie neizdodas, parasti nozīmē, ka baseina maršruts pastāv, bet rezervētās adreses resursdatora maršruts nepastāv.

Pārbaudiet atbildi pirms rezervācijas uzticēšanās

Pārbaudiet AAA pusi un sesijas pusi atsevišķi, jo tās neizdodas dažādu iemeslu dēļ. Lokāls radtest parāda, ko serveris atgriež kontam, neiesaistot vārteju, un lietotāju faila ieraksts parāda, kam serverim jāsakrīt. Pēc tam pievienojiet klientu atkārtoti un salīdziniet saņemto adresi ar atribūtu atbildē.

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 bez atribūta nozīmē, ka serveris nesaskaņoja ierakstu vai atribūts netika piemērots šim lietotājam. Access-Accept ar atribūtu un klients, kurš joprojām saņem baseina adresi, nozīmē, ka vārteja to ignorēja. Access-Reject nosūta jūs atpakaļ pie akreditācijas datiem vai grupas politikas, un neviens no šiem rezultātiem nav jāatkļūdo, rediģējot klienta adapteri.

Atkārtojiet pārbaudi pēc atkārtotas pievienošanas un pēc otras pierakstīšanās no citas ierīces. Rezervācija, kas noturas tikai pirmajai sesijai, ir baseina konflikts, kas gaida notikšanu, un to ir lētāk atrast tagad nekā audita laikā.

Izvēlieties vienu īpašnieku un pierakstiet to

Ja vārteja uzticami piemēro ietvertās adreses, ļaujiet RADIUS pārvaldīt piešķīrumu un noņemiet jebkuru statisku kartējumu tam pašam kontam. Ja ne, ļaujiet vārtejai to pārvaldīt un noņemiet atribūtu no atbildes, lai divi avoti nevarētu atšķirties. Abu paturēšana tāpēc, ka katrs gandrīz darbojas, garantē nākotnes sesiju ar nepareizu adresi un bez acīmredzama iemesla.

Ierakstiet izvēlēto īpašnieku, rezervēto adresi un baseinu, no kura tā nāk, konta ierakstā. Nākamā persona, kas pievienos ierīci, varēs redzēt, vai adrese ir AAA politika vai vārtejas kartējums, pirms mainīt jebkuru no tiem.