Fikseeritud VPN IP: RADIUS Framed-IP-Address või broneering aadressipoolis

Fikseeritud sisemist aadressi VPN-kliendi jaoks võivad hoida kolm kohta ja ainult üks neist peaks seda omama. RADIUS võib aadressi Access-Acceptis tagastada, lüüs võib konto jaoks hoida staatilist vastendust ja kliendi adapterit saab käsitsi seada. Esimesed kaks on poliitika ja kolmas on kohalik oletus, mida lüüs võib vabalt eirata või üle kirjutada. Valik kahe esimese vahel on tegelik otsus ja see sõltub sellest, mida võrgu juurdepääsuserver tegelikult rakendab.

Kolm kohta, kus fikseeritud aadress saab elada

RADIUS omab aadressi, kui vastus kannab Framed-IP-Addressi ja lüüs rakendab selle väärtuse seansile. Lüüs omab seda, kui administraator vastendab konto pooli sees oleva staatilise aadressiga. Klient ei oma midagi, isegi kui tema adapter näitab käsitsi seatud aadressi, sest server määrab sisemise aadressi läbirääkimiste ajal ja kohalik seade loeb ainult siis, kui server ei saada ühtegi. Kõik kolm näevad töötava ühenduse puhul ühesugused välja, mistõttu konfliktid tulevad hilja välja. Erinevus ilmneb taasühendamisel, teisel seadmel ja pärast poliitika muutmist.

Kaks omanikku on konfiguratsioon, mis katkeb. RADIUSi vastus määrab 172.28.4.77, samal ajal kui lüüs hoiab staatilist vastendust 172.28.4.90 jaoks, andes väärtuse, mida tootja kood kontrollib esimesena, ning kaotaja visatakse kõrvale ilma logireata. Sama konto teisel seadmel saab seejärel duplikaatse aadressi ja sümptom loetakse marsruutimistõrke, mitte määramiskonfliktina. Otsustage omanik enne, kui lisate teise mehhanismi.

Kliendipoolset valikut tasub nimetada ainult selleks, et see välistada. Käsitsi seadistatud adapteri aadress on eelistus, mille operatsioonisüsteem võib esitada, mitte broneering, ja see ei saa takistada teist seanssi sama aadressi saamast.

Mida RADIUSi vastus saab ja ei saa lubada

RFC 2865määratleb Framed-IP-Addressi IPv4-aadressina, mis tuleb kasutaja jaoks seadistada, ja see kuulub Access-Accepti. Sama atribuut Access-Requestis on vaid vihje, mida server võib eirata, mis loeb siis, kui klient või lüüs pakub eelistatud aadressi. Miski protokollis ei sunni lüüsi vastust austama, sest võrgu juurdepääsuserver on komponent, mis rakendab selle seansile.

Tugi on toote, mitte protokolli küsimus. Mõned lüüsid rakendavad raamitud aadresse vaikimisi, mõned vajavad enne grupitasandi lüliti sisselülitamist ja mõned võtavad atribuudi vastu ega kasuta seda kunagi kaugjuurdepääsu seansside jaoks. Viimane juhtum on ohtlik, sest arvestuskirje võib vastust näidata, samal ajal kui klient saab pooli aadressi. Kinnitage käitumist täpsel lüüsimudelil ja püsivaras, mida kasutate, mitte sõsartoote dokumentatsioonis.

Vastus, mida lüüs eirab, näeb täpselt välja nagu vastus, mida kunagi ei saadetud. Access-Accepti ja seansi aadressi kõrvuti lugemine on ainus viis neid kahte juhtumit eristada.

Broneerige aadress poolis, mida te juba marsruudite

Valige fikseeritud aadress pooli alamvõrgust, mida lüüs juba marsruudib ja mida tulemüür juba usaldab. Sellest vahemikust väljaspool olev aadress muudab poliitika muudatuse marsruutimisprojektiks ja VPN tõuseb, samal ajal kui miski selle taga ei saa vastata. Kui aadressipõhised juurdepääsureeglid on olemas, lisage fikseeritud aadress neile samas muudatuses.

Otsustage, mida teine samaaegne seanss peaks tegema. Ühe aadressi kaks korda määramine ei ole seadmehaldus ja sellest tulenev kokkupõrge ilmneb katkendliku ühenduvusena mõlema seansi jaoks. Kas väljastage igale seadmele erinev identiteet, erinevad määramised, või nõudke samaaegsust toetatud kontrolliga, näiteks Simultaneous-Use, selle asemel et loota, et klient ei ühendu kunagi uuesti enne vana seansi lõppemist.

Tagasiteed väärivad sama tähelepanu nagu määramine. Lüüs vajab teed pooli, sisemised ruuterid vajavad teed tagasi lüüsini ja fikseeritud aadress pärib mõlemad. Üks klient, mis töötab, samal ajal kui kõik teised ebaõnnestuvad, tähendab tavaliselt, et pooli tee on olemas, kuid broneeritud aadressi hostitee ei ole.

Testige vastust enne, kui usaldate broneeringut

Testige AAA poolt ja seansi poolt eraldi, sest need ebaõnnestuvad erinevatel põhjustel. Kohalik radtest näitab, mida server konto jaoks tagastab ilma lüüsi kaasamata, ja kasutajate faili kirje näitab, millega server peaks kokku langema. Seejärel ühendage klient uuesti ja võrrelge saadud aadressi vastuses oleva atribuudiga.

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 ilma atribuudita tähendab, et server ei sobitanud kirjet või atribuuti ei rakendatud sellele kasutajale. Access-Accept atribuudiga ja klient, kes saab endiselt pooli aadressi, tähendab, et lüüs eiras seda. Access-Reject saadab teid tagasi mandaatide või grupi poliitika juurde ja ühtegi neist tulemustest ei tohiks siluda kliendi adapterit redigeerides.

Korrake kontrolli pärast taasühendamist ja pärast teist sisselogimist teisest seadmest. Broneering, mis peab ainult esimese seansi jaoks, on pooli konflikt, mis ootab juhtumist, ja seda on odavam leida praegu kui auditi ajal.

Valige üks omanik ja kirjutage see üles

Kui lüüs rakendab raamitud aadresse usaldusväärselt, laske RADIUSil määramist omada ja eemaldage sama konto jaoks igasugune staatiline vastendus. Kui mitte, laske lüüsil seda omada ja eemaldage atribuut vastusest, et kaks allikat ei saaks lahkneda. Mõlema hoidmine, sest kumbki peaaegu töötab, tagab tulevase seansi vale aadressiga ja ilma ilmse põhjuseta.

Kirjutage valitud omanik, broneeritud aadress ja pool, kust see pärineb, konto kirjesse. Järgmine inimene, kes seadme lisab, näeb siis, kas aadress on AAA poliitika või lüüsi vastendus, enne kui ta kumbagi muudab.