OpenVPN-serverhulp: netwerk plus netmasker, nooit CIDR

Een serverregel die een CIDR-achtervoegsel met een puntmasker mengt, stopt de daemon voordat hij ooit een poort opent. De hulp server voor IPv4 wil twee afzonderlijke argumenten: een uitgelijnd netwerkadres en daarna het netmasker in puntvorm. Al het andere op die regel is gevolgtrekking, en in de gevolgtrekking gaan poolgroottes en clientmaskers mis.

De twee argumenten die de hulp accepteert

Schrijf eerst het netwerk en dan het masker, met niets aan het adres vast:

server 10.72.16.0 255.255.240.0

Dit is de vorm voor een /20. De regel hieronder is de fout, en die mislukt bij het parsen van opties, niet tijdens runtime:

server 10.72.16.0/20 255.255.240.0

Houd de twee ideeën gescheiden wanneer je dit debugt. Een prefixlengte en een puntmasker beschrijven dezelfde span, maar de hulp accepteert niet beide tegelijk, en een afgewezen regel levert een optiefout op die de richtlijn noemt en niet de rekenkunde.

Lijn het netwerk uit voordat je het masker typt

Het eerste adres is het netwerkadres van het bereik, niet een handig clientadres erbinnen. Voor een /20 loopt de span van 10.72.16.0 tot 10.72.31.255, en alleen het eerste daarvan is een geldig netwerkargument. Een /21 gebruikt 255.255.248.0 en omvat 10.72.16.0 tot 10.72.23.255, dus de regel is server 10.72.16.0 255.255.248.0.

Het prefix wijzigen wijzigt de span en niets anders. Het wijzigt niet hoeveel adressen één client krijgt, want dat is een eigenschap van de topologie, niet van het masker op deze regel.

Bevestig de pool vanaf de serverkant

Start de instantie op de voorgrond met uitgebreide logging en lees de regels die de hulp uitstuurt. De pool die hij bouwde wordt bij het opstarten afgedrukt, wat betrouwbaarder is dan de rekenkunde met de hand uitwerken:

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

Zoek de poolsamenvatting bovenaan de uitvoer. Die somt het bereik op dat de hulp reserveerde, en als dat bereik niet overeenkomt met je bedoeling, zijn de argumenten op de regel verkeerd, wat de maskerrekenkunde ook zegt.

Verbind daarna één client en zoek de regel die het adres vastlegt dat hij kreeg. Dat ene adres, naast het poolbereik, vertelt je of de client binnen het gereserveerde blok landde of ergens waar je het niet verwachtte. Als de twee niet overeenkomen, repareer de argumenten en niet de client. Als ze overeenkomen en de client bereikt nog steeds niets, was de pool nooit het probleem.

Lees het masker van de client met de topologie in gedachten

Een client die een /30 op zijn tunnelinterface toont, is geen bewijs van een kapotte pool. Bij punt-naar-puntadressering krijgt elke client een klein blok en zijn interfacemasker beschrijft dat blok, terwijl de pool van de server het geheel dekt. Bij een subnet-topologie komt het masker van de client juist overeen met het poolmasker. Het masker alleen vertelt dus welke topologie in het spel is, niet of de pool correct is geschreven.

Controleer de geconfigureerde topologie en het toegewezen adres samen voordat je een conclusie trekt:

ip -4 addr show tun0

Als het adres binnen de pool ligt en het masker smaller is dan de pool, dan doet de topologie zijn werk. Als het adres buiten de pool ligt, is de pool verkeerd, en geen enkele inspectie aan de clientkant zal dat repareren.

Een live pool wijzigen

Kies een bereik dat niet overlapt met de huidige pool, het LAN of een route die al naar clients is gepusht. Overlap is de fout die een herstart overleeft en dan dagen later opduikt als één locatie die vanuit één richting onbereikbaar is.

Wijzig de regel, herstart en lees de opstartpool opnieuw voordat je gebruikers teruglaat. Als het nieuwe bereik met iets botst, toont dezelfde opstartuitvoer het meteen, en terugdraaien is een wijziging van één regel plus nog een herstart.

Houd het oude bereik na de wijziging nog een tijdje gereserveerd. Clients die laat opnieuw verbinden kunnen nog een adres uit de vorige pool hebben, en een nieuw bereik dat die adressen hergebruikt, levert dubbele toewijzingen op die op een routeringsfout lijken. De OpenVPN 2.6-handleiding documenteert de argumenten van de hulp en de uitbreiding ervan, wat de moeite waard is om te lezen voordat je aanneemt dat een richtlijn dezelfde notatie gebruikt als zijn buurman.