Staattinen OpenVPN-IP asiakaskohtaisesti: ifconfig-push, ei ipp.txt

Rivin muokkaaminen tiedostossa ipp.txt tuntuu osoitteen varaamiselta, mutta sitä se ei ole. Tämä tiedosto, jonka nimi tulee ifconfig-pool-persist-asetuksesta, tallentaa, mikä osoite yhteisnimellä oli viimeksi, jotta allas voi palauttaa saman, kun se sopii. Mikään siinä ei sido seuraavaa yhteyttä tuohon numeroon.

Suorita alla olevat tarkistukset järjestyksessä. Jokainen joko vahvistaa mekanismin tai käskee pysähtyä ja korjata syöte.

Mihin pysyvyystiedosto on tarkoitettu

Tiedosto on olemassa, jotta osoitteet pysyisivät vakaina uudelleenkäynnistysten yli, mikä tekee uudelleenyhdistämisistä ystävällisempiä ja lokeista helpompia lukea. Se luetaan historiana ja kirjoitetaan historiana, ja jakopolku saa vapaasti valita toisen osoitteen, kun vihje ei sovi: toinen allas, ristiriitainen määritys tai asiakas, joka saapui sen jälkeen kun allas täyttyi. Siksi käsin tehty muutos voi näyttää tiedostossa täydelliseltä eikä muuta yhteydessä mitään. Käsittele sitä menneiden päätösten välimuistina, älä käytännön lähteenä.

Jos tarvitset tietyn osoitteen tietylle asiakkaalle, dokumentoitu mekanismi on ifconfig-push, ja se kuuluu sen asiakkaan omistamaan kokoonpanoon.

Tarkista, että oikea asiakas on valittu

Eksplisiittinen määritys haetaan asiakkaan yhteisnimellä, joten väärälle identiteetille nimettyä tiedostoa ei yksinkertaisesti koskaan lueta. Vahvista, mitä palvelin pitää kyseisen asiakkaan nimenä, erityisesti siellä, missä username-as-common-name muuttaa sitä todennuksen jälkeen. Vahvista sitten, että tiedostonimi vastaa täsmälleen tuota arvoa, myös kirjainkoon osalta.

Mieti samanaikaisuutta täällä ollessasi. Jos duplicate-cn on sallittu, useat laitteet voivat esittää saman identiteetin, eikä yksi kiinteä osoite voi olla ainutlaatuinen kaikille niille. Päätä, onko kiinteä osoite sen arvoinen, että kyseisen identiteetin samanaikaiset istunnot hylätään, koska näitä kahta vaatimusta ei voi täyttää samanaikaisesti.

Tarkista, että numerot vastaavat topologiaa

Argumenttien merkitys riippuu tunnelin topologiasta, ja juuri tässä kopioitu esimerkki aiheuttaa eniten vahinkoa. Vanhemmassa net30-järjestelyssä jokainen asiakas vie neljän osoitteen lohkon, joten push antaa osoiteparin. Aliverkkotopologiassa asiakas saa yhden osoitteen plus altaan peitteen, ja parin muoto on väärä. Lue topologia käynnissä olevasta kokoonpanosta ennen rivin kirjoittamista.

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

Tarkista osoite kaikkea muuta vastaan, mikä voisi omistaa sen: toinen eksplisiittinen määritys, dynaamisen altaan alue ja mikä tahansa staattinen reitti, joka olettaa kiinteän isäntäkoneen. Altaan kanssa päällekkäinen osoite toimii, kunnes allas antaa sen jollekulle toiselle, ja tuo vika näyttää satunnaiselta.

Tarkista tulos uudella yhteydellä

Olemassa oleva istunto pitää saamansa osoitteen, joten ainoa mielekäs testi on uusi yhteys. Katkaise asiakkaan yhteys, yhdistä uudelleen ja lue osoite, jonka se todella sai, yhdessä sen mukana tulleiden reittien kanssa. Jos osoite on edelleen dynaaminen, määritystä ei otettu käyttöön, ja seuraava askel on kokoonpanon etsintä eikä uusi muokkaus historiatiedostoon.

Pidä todisteet yhdessä: asiakasnimi, sopinut tiedosto, määritetty osoite ja allas, josta se tuli.

Lopuksi, kiinteä tunneliosoite ei ole laitteen tunnistetieto. Se osoittaa paikan osoitesuunnitelmassa, kun taas todennus nojaa edelleen varmenteeseen ja tiliin. Näiden kahden sekoittaminen muuttaa osoitekonfliktin turvallisuusoletukseksi, jota kukaan ei kirjoittanut.