Statinis OpenVPN IP kiekvienam klientui: ifconfig-push, o ne ipp.txt

Eilutės redagavimas ipp.txt atrodo kaip adreso rezervavimas, bet tai ne tai. Šis failas, kurį pavadina ifconfig-pool-persist, įrašo, kokį adresą bendras vardas turėjo paskutinį kartą, kad telkinys galėtų grąžinti tą patį, kai tai patogu. Niekas jame nesaisto kito prisijungimo su tuo numeriu.

Atlikite toliau pateiktus patikrinimus iš eilės. Kiekvienas jų arba patvirtina mechanizmą, arba liepia sustoti ir pataisyti įvestį.

Kam skirtas persistencijos failas

Failas egzistuoja tam, kad adresai išliktų stabilūs tarp perkrovimų, o tai daro pakartotinius prisijungimus patogesnius ir žurnalus lengviau skaitomus. Jis skaitomas kaip istorija ir rašomas kaip istorija, o paskirstymo kelias lieka laisvas pasirinkti kitą adresą, kai užuomina netinka: kitas telkinys, prieštaringas priskyrimas arba klientas, atėjęs po to, kai telkinys prisipildė. Todėl rankinis redagavimas gali atrodyti tobulas faile ir nieko nepakeisti ryšyje. Traktuokite jį kaip praeities sprendimų talpyklą, o ne politikos šaltinį.

Jei jums reikia konkretaus adreso konkrečiam klientui, dokumentuotas mechanizmas yra ifconfig-push, ir jis priklauso konfigūracijai, kuri valdo tą klientą.

Patikrinkite, ar pasirinktas tinkamas klientas

Aiškus priskyrimas ieškomas pagal kliento bendrą vardą, todėl failas, pavadintas netinkama tapatybe, tiesiog niekada nėra skaitomas. Patvirtinkite, ką serveris laiko to kliento vardu, ypač ten, kur username-as-common-name jį pakeičia po autentifikacijos. Tada patvirtinkite, kad failo vardas tiksliai atitinka tą reikšmę, įskaitant didžiąsias ir mažąsias raides.

Pagalvokite apie paralelumą, kol esate čia. Jei duplicate-cn leidžiamas, keli įrenginiai gali pateikti tą pačią tapatybę, o vienas fiksuotas adresas negali būti unikalus visiems. Nuspręskite, ar fiksuotas adresas vertas atsisakyti lygiagrečių sesijų tai tapatybei, nes šių dviejų reikalavimų negalima patenkinti vienu metu.

Patikrinkite, ar skaičiai atitinka topologiją

Argumentų reikšmė priklauso nuo tunelio topologijos, ir būtent čia nukopijuotas pavyzdys padaro daugiausia žalos. Senesnėje net30 schemoje kiekvienas klientas užima keturių adresų bloką, todėl push pateikia adresų porą. Potinklio topologijoje klientas gauna vieną adresą ir telkinio kaukę, o poros forma yra neteisinga. Perskaitykite topologiją iš veikiančios konfigūracijos prieš rašydami eilutę.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Patikrinkite adresą prieš visa kita, kas galėtų jį turėti: kitą aiškų priskyrimą, dinaminio telkinio diapazoną ir bet kokį statinį maršrutą, kuris numato fiksuotą mazgą. Adresas, kuris persidengia su telkiniu, veiks tol, kol telkinys atiduos jį kam nors kitam, ir ta klaida atrodys atsitiktinė.

Patikrinkite rezultatą naujame prisijungime

Esama sesija išlaiko jai duotą adresą, todėl vienintelis prasmingas testas yra naujas prisijungimas. Atjunkite klientą, prisijunkite iš naujo ir perskaitykite adresą, kurį jis iš tikrųjų gavo, kartu su maršrutais, kurie atėjo su juo. Jei adresas vis dar dinaminis, priskyrimas nebuvo pritaikytas, o kitas žingsnis yra konfigūracijos paieška, o ne dar vienas istorijos failo redagavimas.

Laikykite įrodymus kartu: kliento vardą, atitikusį failą, priskirtą adresą ir telkinį, iš kurio jis atėjo.

Galiausiai, fiksuotas tunelio adresas nėra įrenginio prisijungimo duomenys. Jis žymi vietą adresų plane, o autentifikacija vis dar remiasi sertifikatu ir paskyra. Sumaišius abu, adresų konfliktas virsta saugumo prielaida, kurios niekas neužrašė.