Statisch OpenVPN-IP per client: ifconfig-push, niet ipp.txt

Een regel in ipp.txt bewerken voelt als het reserveren van een adres, en dat is het niet. Dat bestand, genoemd door ifconfig-pool-persist, legt vast welk adres een gemeenschappelijke naam de vorige keer had, zodat de pool hetzelfde kan teruggeven wanneer dat uitkomt. Niets erin bindt de volgende verbinding aan dat nummer.

Voer de onderstaande controles in volgorde uit. Elk bevestigt het mechanisme of zegt dat u moet stoppen en een invoer moet repareren.

Waarvoor het persistentiebestand dient

Het bestand bestaat om adressen stabiel te houden tussen herstarts, wat herverbindingen vriendelijker en logboeken leesbaarder maakt. Het wordt als geschiedenis gelezen en als geschiedenis geschreven, en het toewijzingspad blijft vrij om een ander adres te kiezen wanneer de hint niet past: een andere pool, een conflicterende toewijzing of een client die aankwam nadat de pool vol was. Daarom kan een handmatige bewerking er in het bestand perfect uitzien en niets aan de verbinding veranderen. Behandel het als een cache van eerdere beslissingen, niet als een bron van beleid.

Als u een specifiek adres voor een specifieke client nodig hebt, is het gedocumenteerde mechanisme ifconfig-push, en het hoort in de configuratie die die client bezit.

Controleer of de juiste client is geselecteerd

Een expliciete toewijzing wordt opgezocht op de gemeenschappelijke naam van de client, dus een bestand dat op de verkeerde identiteit is genoemd, wordt gewoon nooit gelezen. Bevestig wat de server als de naam van die client beschouwt, vooral waar username-as-common-name die na authenticatie wijzigt. Bevestig daarna dat de bestandsnaam exact met die waarde overeenkomt, inclusief hoofdletters en kleine letters.

Denk aan gelijktijdigheid terwijl u hier bent. Als duplicate-cn is toegestaan, kunnen meerdere apparaten dezelfde identiteit presenteren, en één vast adres kan niet voor allemaal uniek zijn. Beslis of het vaste adres het waard is om gelijktijdige sessies voor die identiteit te weigeren, want die twee vereisten kunnen niet tegelijk worden vervuld.

Controleer of de nummers bij de topologie passen

De betekenis van de argumenten hangt af van de tunnel-topologie, en hier richt een gekopieerd voorbeeld de meeste schade aan. In de oudere net30-indeling neemt elke client een blok van vier adressen in, dus levert de push een paar adressen. In subnet-topologie ontvangt de client één adres plus het masker van de pool, en de paar-vorm is verkeerd. Lees de topologie uit de draaiende configuratie voordat u de regel schrijft.

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

Controleer het adres tegen alles wat het zou kunnen bezitten: een andere expliciete toewijzing, het bereik van de dynamische pool en elke statische route die een vaste host veronderstelt. Een adres dat de pool overlapt, werkt totdat de pool het aan iemand anders geeft, en die fout zal willekeurig lijken.

Controleer het resultaat op een nieuwe verbinding

Een bestaande sessie behoudt het adres dat zij kreeg, dus de enige zinvolle test is een nieuwe verbinding. Verbreek de verbinding van de client, maak opnieuw verbinding en lees het adres dat hij werkelijk ontving samen met de routes die ermee aankwamen. Als het adres nog dynamisch is, is de toewijzing niet toegepast, en de volgende stap is het opzoeken in de configuratie in plaats van nog een bewerking van het geschiedenisbestand.

Houd de bewijzen bij elkaar: de clientnaam, het bestand dat overeenkwam, het toegewezen adres en de pool waaruit het kwam.

Ten slotte, een vast tunneladres is geen apparaatreferentie. Het markeert een plaats in het adresplan, terwijl authenticatie nog steeds op het certificaat en het account rust. De twee verwarren maakt van een adresconflict een beveiligingsaanname die niemand heeft opgeschreven.