OpenVPN-server med nopool: deklarera ett explicit poolområde

Serverhjälparna konfigurerar ett undernät och fyller det sedan med en dynamisk pool enligt eget val. Den standarden är bekväm tills vissa adresser måste hållas utanför tilldelningen — antingen de är reserverade för fasta tilldelningar eller undanhållna för ett framtida segment. Att undertrycka den automatiska poolen och deklarera området själv kräver två rader och ett medvetet beslut om vilka adresser som inte är för tilldelning. Resten är operativ disciplin: inventering, tillämpning, verifiering, återställning.

Detta är en ändring i en tjänst som körs, så behandla den som en operativ uppgift: inventering först, tillämpning genom den normala livscykeln, verifiering med en ny klient och en förberedd återställning.

Börja med undernätet du redan har

Läs den aktuella serverkonfigurationen och de adresser som klienterna faktiskt håller. Pooländringen ger bara mening mot den baslinjen, och baslinjen är inte alltid vad filen antyder, eftersom en hanterad produkt eller en konfigurationsgenerator kan äga filen du läser.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Bekräfta topologin som gäller. Under undernätstopologi tar varje klient en adress från poolen; äldre net30-layouter tilldelar ett litet block per klient och aritmetiken är helt annorlunda. Om servern fortfarande ligger på net30 är den här sidan fel migreringsguide och pooltalen kommer inte att betyda det du förväntar dig. Kontrollera den raden innan du kopierar adressaritmetik från annat håll.

Skriv ner serverns egen adress, varje fast tilldelning i katalogen för klientkonfigurationer och varje adress som en rutt eller en åtkomstregel är beroende av. Det är dessa adresser som måste hållas utanför det dynamiska området. Att skriva ner dem först är det som gör området till ett beslut i stället för en gissning. Det ger också en återställning något konkret att återställa.

Lägg till nopool och deklarera området

Hjälpnyckelordet accepterar nopool, som behåller undernätskonfigurationen och undertrycker den automatiska dynamiska poolen, vilket OpenVPN 2.6-handboken beskriver. Den explicita raden ifconfig-pool ger sedan det inkluderande område du avser, och dess nätmask matchar undernätet. Båda raderna hör till samma serverblock, eftersom en pool utan sitt undernät inte har någon betydelse. Ordningen mellan dem spelar bara roll för läsbarheten, eftersom hjälparen vecklar ut paret när tjänsten startar.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Båda gränserna är inkluderande, så exemplet erbjuder sjuttioen adresser. Håll serveradressen och varje fast tilldelning utanför det spannet; en fast tilldelning inne i det dynamiska området ger en kollision som beror på anslutningsordningen, och det är den värsta sorten att felsöka. Lämna en marginal mellan den reserverade mängden och området om de fasta tilldelningarna sannolikt kommer att växa.

Områdets storlek och samtidighet är separata gränser. Hundra adresser betyder inte hundra samtidiga klienter om max-clients säger något annat, och en pool som är större än samtidighetsgränsen är normalt och inte slöseri. Det viktiga är att de två gränserna väljs medvetet i stället för att ärvas från en standard.

Håll fasta tilldelningar utanför det dynamiska området

En klientspecifik ifconfig-push är en annan mekanism än tilldelning från poolen, och den måste använda parametrar som passar den aktiva topologin. I undernätsläge är det en enda adress och nätmask; att föra över ett net30-par för att det förekom i ett gammalt exempel är ett vanligt fel.

Tilldelningshistorik är en ledtråd, inte en auktoritet. En persist-fil minns vilken klient som hade vilken adress, så klienter som återansluter tenderar att få samma, och den reserverar inte adresser, frigör dem inte eller ersätter en fast tilldelning. Om en viss enhet alltid måste ha en viss adress, använd en fast tilldelning i stället för att lita på persist-filen.

Kontrollera sedan de banor som är beroende av adresser. En rutt som skjuts ut till klienterna, en brandväggsregel som släpper in ett undernät, eller en övervakningskontroll som förväntar sig en viss värd kan alla förutsätta det gamla området. Att ändra poolen utan att läsa dem flyttar felet till en plats som verkar orelaterad.

Tillämpa genom livscykeln och verifiera sedan

Tillämpa ändringen så som tjänsten vanligtvis tar emot konfiguration — antingen en direkt fil plus omstart eller ett hanteringslager som genererar om filen. En manuell ändring i en genererad fil överlever till nästa generering, och inte längre. Notera vilken mekanism som äger filen, eftersom nästa operatör behöver veta var samma ändring ska göras. Starta sedan om en gång och läs loggen innan du bjuder in en klient.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Anslut en klient som inte varit ansluten tidigare och bekräfta att adressen ligger inom det deklarerade området och utanför den reserverade mängden. Bekräfta sedan returvägen: klienten ska nå det som policyn tillåter och inget mer. En adress som passar planen men inte har en fungerande rutt är inte en lyckad ändring.

Anslut en klient som hade en adress från det gamla området på nytt. Den ska få en adress från det nya området, och all sessionsnivåstatus knuten till den gamla adressen ska vara borta. Om den behåller den gamla adressen är det något annat som tilldelar den, och poolen är inte den ägare du tror.

Återställning av en områdesändring

Behåll de tre föregående raderna i din ändringslogg, inte bara den föregående filen. Att återställa dem och starta om för tilldelningen tillbaka till det gamla beteendet, och klienter som ansluter efteråt får adresser därifrån.

Två varningar hör hemma i loggen. Klienter som redan är anslutna när du återställer behåller sina nuvarande adresser tills de återansluter, så en återställning är inte omedelbar i hela flottan. Och om det gamla området överlappade en fast tilldelning återställer en återställning också kollisionen; just den överlappningen var skälet till ändringen, och den kräver en annan lösning än en återställning.

En pooländring är klar när en ny klient får en adress inom området, en reserverad adress aldrig delas ut och rutterna och reglerna som använder dessa adresser fortfarande beter sig som avsett. Allt mindre lämnar åt nästa person att ta reda på vilken av de tre som inte stämmer.