Vilken adress delar poolen ut vid nästa återanslutning?

En regel som passade i går passar inte i dag, eftersom klienten kom tillbaka på en annan tunneladress. Allokeraren är dock inte slumpmässig, och den som känner till ordningen gör den överraskningen till en förutsägbar händelse. Den föredrar adressen som samma klient hade tidigare, faller tillbaka på den längst oanvända lediga och glömmer allt om du inte ger den någonstans att minnas. Regler som förutsätter en lease fortsätter att passa till den dag de tyst slutar göra det.

Ordningen som allokeraren följer

Med en session per common name letar allokeraren först efter en adress som samma klient använde tidigare och som är ledig nu. Är den adressen borta tar den den lediga adressen som varit oanvänd längst. Med samtidiga sessioner för samma namn gäller inte företrädet för den tidigare adressen, och i stället används den första lediga adressen, eftersom sessionerna behandlas som separata peers.

Två följder kommer direkt. En klient som återansluter snabbt behåller oftast sin adress, och därför märker ingen mekanismen förrän den ändras. Och en annan enhet som ansluter under det lilla fönstret kan ta adressen medan den är kortvarigt ledig, varefter den första klienten får något annat och varje regel som pekar på det gamla numret är fel. Ingen av de två händelserna ger en logglinje som ser ut som ett fel.

Varför en lease ser stabil ut och sedan flyttar sig

Stabilitet är här en framväxande egenskap hos återanslutningar som anländer innan någon annan gör anspråk på adressen. Det är inte ett löfte, och det upprätthålls inte medan klienten är frånkopplad. Planera för att adressen ändras i stället för att bli överraskad av det. En pool som knappt är större än antalet enheter gör kollisioner till vardag, eftersom återfallet till den längst oanvända adressen nästan inte har något att välja mellan.

Toppsamtidighet är talet man dimensionerar efter, inte antalet användare. Någon som testar från två enheter samtidigt, eller en klient som återansluter innan den gamla sessionen löper ut, upptar två leases ett tag. En pool som bara är dimensionerad för antalet personer ger precis den omsättning som folk skyller på servern.

Persistensfilen minns, den reserverar inte

En adress som överlever en tjänsteomstart behöver en persistensfil. Den sparar klientnamn och adress vid avstängning och läser in dem igen när tjänsten startar, och därför blandar en planerad omstart inte längre om alla regler du skrev.

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

Det den inte gör är att hålla kvar adressen medan klienten är borta. I det gapet får allokeraren ge numret till någon annan, och filen registrerar då en inaktuell preferens som nästa anslutning inte kan uppfylla. Behandla den som en ledtråd som förbättrar omstartsbeteendet, inte som statisk adressering.

Kontrollera poolen mot varje routat subnät medan du är i filen. Ett överlappande intervall delar ut adresser som servern inte kan routa till, och symtomet är en klient som ansluter, får en adress och inte når något.

Att fästa en adress ordentligt

När en brandväggsregel eller en DNS-post verkligen behöver en fast adress, tilldela den i stället för att hoppas på den. En konfigurationspost per klient kan skicka ut en adress och mask direkt, och den posten är nycklad till det effektiva klientnamnet.

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

Håll fasta adresser utanför den dynamiska poolen så att allokeraren aldrig ger samma nummer till en annan session. Kontrollera sedan tunneltopologin, eftersom den ändrar hur många pooladresser varje klient förbrukar: den äldre punkt-till-punkt-layouten förbrukar ett litet block per klient, medan en subnetlayout använder en adress var. En pool som ser generös ut under den ena topologin kan vara uttömmande under den andra.

Bekräfta resultatet på klienten i stället för att lita på serverns bokföring. När sessionen är tillbaka, titta på gränssnittsadressen och den pushade rutten, eftersom en logg på servern kan rapportera adressen som begärdes medan gränssnittet självt har en annan.

Fjärradressen är en separat fråga

Adressen i klientens remote-rad måste vara nåbar innan någon tunnel finns. Sätter man en pooladress där, till exempel serverns egen tunneländpunkt, försöker klienten nå ändpunkten genom en tunnel den ännu inte har byggt, och resultatet blir en slinga eller en tyst timeout i stället för en genväg.

Använd den offentliga ändpunkt som operatören angav, och håll poolen till det den är gjord för: adresser inne i tunneln. Att anteckna poolintervallet, de fasta tilldelningarna och persistenssökvägen på ett ställe sparar nästa person från att behandla varje lease som godtycklig.