Statiese OpenVPN-IP per kliënt: ifconfig-push, nie ipp.txt nie

'n Reël in ipp.txt redigeer voel soos om 'n adres te reserveer, en dit is nie een nie. Daardie lêer, wat deur ifconfig-pool-persist benoem word, teken aan watter adres 'n common name laas gehad het, sodat die poel dieselfde adres kan teruggee wanneer dit gerieflik is. Niks daarin bind die volgende verbinding aan daardie nommer nie.

Voer die kontroles hieronder in volgorde uit. Elkeen bevestig óf die meganisme óf sê vir jou om te stop en 'n invoer te herstel.

Waarvoor die persistemtelêer dien

Die lêer bestaan om adresse oor herstarts heen stabiel te hou, wat herverbindings vriendeliker en logs makliker leesbaar maak. Dit word as geskiedenis gelees en as geskiedenis geskryf, en die toekenningspad bly vry om 'n ander adres te kies wanneer die wenk nie pas nie: 'n ander poel, 'n botsende toekenning, of 'n kliënt wat opgedaag het nadat die poel vol was. Daarom kan 'n handmatige wysiging in die lêer volmaak lyk en niks aan die verbinding verander nie. Behandel dit as 'n kas van vorige besluite eerder as 'n bron van beleid.

As jy 'n spesifieke adres vir 'n spesifieke kliënt nodig het, is die gedokumenteerde meganisme ifconfig-push, en dit hoort in die konfigurasie wat daardie kliënt besit.

Kontroleer dat die regte kliënt gekies is

'n Eksplisiete toekenning word op die kliënt se common name nageslaan, so 'n lêer wat vir die verkeerde identiteit benoem is, word eenvoudig nooit gelees nie. Bevestig wat die bediener as daardie kliënt se naam beskou, veral waar username-as-common-name dit ná verifikasie verander. Bevestig dan dat die lêernaam presies met daardie waarde ooreenstem, insluitend hoofletters.

Oorweeg gelyktydigheid terwyl jy hier is. As duplicate-cn toegelaat word, kan verskeie toestelle dieselfde identiteit voorhou, en een vaste adres kan nie vir almal uniek wees nie. Besluit of die vaste adres werd is om gelyktydige sessies vir daardie identiteit te weier, want daardie twee vereistes kan nie albei bevredig word nie.

Kontroleer dat die nommers by die topologie pas

Die betekenis van die argumente hang van die tonnel-topologie af, en dit is waar 'n gekopieerde voorbeeld die meeste skade doen. In die ouer net30-reëling beslaan elke kliënt 'n blok van vier adresse, so die push voorsien 'n paar adresse. In subnet-topologie ontvang die kliënt een adres plus die poel se masker, en die paarvorm is verkeerd. Lees die topologie uit die lopende konfigurasie voordat jy die reël skryf.

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

Kontroleer die adres teen alles anders wat dit kan besit: nog 'n eksplisiete toekenning, die dinamiese poelreeks, en enige statiese roete wat 'n vaste gasheer veronderstel. 'n Adres wat die poel oorvleuel, sal werk totdat die poel dit aan iemand anders gee, en daardie mislukking sal willekeurig lyk.

Kontroleer die resultaat op 'n nuwe verbinding

'n Bestaande sessie behou die adres wat dit gekry het, so die enigste sinvolle toets is 'n nuwe verbinding. Verbreek die kliënt se verbinding, verbind weer, en lees die adres wat dit werklik ontvang het saam met die roetes wat daarmee saamgekom het. As die adres steeds dinamies is, is die toekenning nie toegepas nie, en die volgende stap is die konfigurasie-opsoek eerder as nog 'n wysiging aan die geskiedenislêer.

Hou die bewyse bymekaar: die kliëntnaam, die lêer wat gepas het, die adres wat toegeken is en die poel waaruit dit gekom het.

Laastens, 'n vaste tonneladres is nie 'n toestelbewys nie. Dit dui 'n plek in die adresplan aan, terwyl verifikasie steeds op die sertifikaat en die rekening berus. Om die twee te verwar, maak van 'n adreskonflik 'n sekuriteitsaanname wat niemand neergeskryf het nie.