OpenVPN-serverhjälp: nätverk plus nätmask, aldrig CIDR

En serverrad som blandar ett CIDR-suffix med en punktad mask stoppar daemonen innan den ens öppnar en port. Hjälpen server för IPv4 vill ha två separata argument: en justerad nätverksadress och därefter nätmasken i punktad form. Allt annat på den raden är gissning, och i gissningen går poolstorlekar och klientmasker fel.

De två argumenten som hjälpen accepterar

Skriv nätverket först och masken sedan, utan något fäst vid adressen:

server 10.72.16.0 255.255.240.0

Detta är formen för ett /20. Raden nedan är felet, och det fallerar vid tolkning av alternativ, inte vid körning:

server 10.72.16.0/20 255.255.240.0

Håll de två idéerna åtskilda när du felsöker detta. En prefixlängd och en punktad mask beskriver samma intervall, men hjälpen accepterar inte båda samtidigt, och en avvisad rad ger ett alternativfel som namnger direktivet och inte aritmetiken.

Justera nätverket innan du skriver masken

Den första adressen är nätverksadressen för intervallet, inte en bekväm klientadress inuti det. För ett /20 går intervallet från 10.72.16.0 till 10.72.31.255, och bara den första av dem är ett giltigt nätverksargument. Ett /21 använder 255.255.248.0 och spänner från 10.72.16.0 till 10.72.23.255, så dess rad är server 10.72.16.0 255.255.248.0.

Att ändra prefixet ändrar intervallet och inget annat. Det ändrar inte hur många adresser en enskild klient får, eftersom det är en egenskap hos topologin, inte hos masken på den här raden.

Bekräfta poolen från serversidan

Starta instansen i förgrunden med detaljerad loggning och läs raderna som hjälpen skriver ut. Poolen som den byggde skrivs ut vid start, vilket är pålitligare än att räkna aritmetiken för hand:

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

Leta efter poolsammanfattningen nära toppen av utdata. Den listar intervallet som hjälpen reserverade, och om det intervallet inte stämmer med din avsikt är argumenten på raden fel, vad maskaritmetiken än säger.

Anslut sedan en klient och hitta raden som registrerar adressen den fick. Den enda adressen, bredvid poolintervallet, berättar om klienten landade inne i det reserverade blocket eller någonstans du inte förväntade dig. Om de två inte stämmer, rätta argumenten och inte klienten. Om de stämmer och klienten fortfarande inte når något, var poolen aldrig problemet.

Läs klientens mask med topologin i åtanke

En klient som visar ett /30 på sitt tunnelgränssnitt är inte bevis på en trasig pool. Vid punkt-till-punkt-adressering får varje klient ett litet block och dess gränssnittsmask beskriver det blocket, medan serverns pool täcker helheten. Vid en subnätstopologi stämmer klientens mask i stället med poolens mask. Masken ensam säger alltså vilken topologi som är i spel, inte om poolen är korrekt skriven.

Kontrollera den konfigurerade topologin och den tilldelade adressen tillsammans innan du drar en slutsats:

ip -4 addr show tun0

Om adressen ligger inom poolen och masken är snävare än poolen, är det topologin som gör sitt jobb. Om adressen ligger utanför poolen är poolen fel, och ingen inspektion på klientsidan kommer att rätta det.

Ändra en aktiv pool

Välj ett intervall som inte överlappar den aktuella poolen, LAN:et eller någon rutt som redan har skickats till klienter. Överlapp är felet som överlever en omstart och sedan, dagar senare, dyker upp som en plats som är onåbar från ett håll.

Ändra raden, starta om och läs om startpoolen innan du släpper in användarna igen. Om det nya intervallet krockar med något visar samma startutdata det direkt, och en återställning är en ändring av en rad plus ännu en omstart.

Behåll det gamla intervallet reserverat ett tag efter ändringen. Klienter som ansluter sent kan fortfarande hålla en adress från den förra poolen, och ett nytt intervall som återanvänder dessa adresser ger dubbla tilldelningar som ser ut som ett routingfel. OpenVPN 2.6-handboken dokumenterar hjälpens argument och dess expansion, vilket är värt att läsa innan du antar att ett direktiv använder samma notation som sin granne.