Gateway-gebruiker in Access Server: het filiaal-LAN van een client routeren

U kunt het tunneladres van een OpenVPN-client pingen en toch geen host bereiken op het LAN erachter. Access Server geeft die client een adres uit de VPN-pool, en het pooladres is alles wat de server als zijn eigendom kent. Het filiaalprefix is een apart gegeven dat gedeclareerd moet worden, en zelfs dan heeft het filiaal een doorstuurder nodig en het hoofdkantoor een terugweg. Een route op de verkeerde plek lijkt een oplossing en verandert niets.

Twee adressen, twee verschillende eigendomsclaims

Wanneer een client verbindt, wijst Access Server hem een adres uit de geconfigureerde VPN-pool toe, bijvoorbeeld 10.90.0.0/24. Die toewijzing is een lease voor één host. Niets in de verbinding zegt dat dezelfde client ook voor 10.60.0.0/24 staat, en de server zal niet gokken: een LAN-prefix is alleen via een bepaalde client bereikbaar als een beheerder dat declareert.

Daarom werkt een statische route op een andere machine niet. De route zegt stuur 10.60.0.0/24 naar dit adres, maar als het adres bij een client hoort die nooit als gateway is gemarkeerd, heeft de server geen reden die pakketten daar af te leveren, en de stack van de client kan ze weggooien. De declaratie en de route zijn twee helften van één mechanisme.

Wat de gateway-instelling werkelijk installeert

In de Admin Web UI is de declaratie een gebruikerseigenschap: schakel Configure VPN gateway in bij de connector-gebruiker en voer het echte filiaalprefix in bij Network on the VPN client side. Die gebruiker authenticeert als elke andere, dus heeft hij een credentialbeleid nodig dat bij een onbeheerd apparaat past, en zijn auto-loginprofiel is een geheim, geen gemaksbestand.

Achter dat vakje behandelt de server het prefix als bereikbaar via het pooladres van die client, en de routingconfiguratie onder Access Controls bepaalt wat andere clients te horen krijgen: de routes die naar gewone clients worden gestuurd en de toegangsregels die verkeer van de hoofdkantoornetwerken naar clientadressen en subnets toestaan. Schakel routing in voor de netwerken die het filiaal moeten bereiken en houd de toegestane lijst kort.

Een Community-achtige richtlijn die in een gegenereerd bestand wordt geplakt, doet niet mee in dit model. Het product bezit de routingtabel die het pusht; een handmatig bewerkte regel wordt overschreven of genegeerd.

Voltooi beide terugwegen van de netwerken

Een concreet plan: hoofdkantoor 10.40.0.0/24, filiaal 10.60.0.0/24, VPN-pool 10.90.0.0/24, en Access Server bereikbaar op een privéadres aan de kant van het hoofdkantoor. De router van het hoofdkantoor heeft routes nodig voor het filiaalprefix en voor de pool, beide naar Access Server. Zonder die verlaat het antwoord via de standaardgateway, wat de klassieke halfopen verbinding oplevert.

In het filiaal moet de connector pakketten doorsturen die niet aan hemzelf zijn gericht: IP-doorsturen in zijn besturingssysteem plus een doorstuurtpermisie beperkt tot de tunnel- en LAN-interfaces; op Linux is dat net.ipv4.ip_forward=1 met de forward-ketenregels, op Windows is dat routing and remote access. Daarna hebben de hosts in het filiaal een terugweg nodig: ofwel is de connector hun standaardgateway, ofwel draagt de bestaande gateway specifieke routes voor de prefixen van het hoofdkantoor en de pool.

De routingtabel van de connector herconfigureert niet elke host op het filiaal-LAN. Als de hosts naar een andere router wijzen, horen de terugroutes daar, en die moet accepteren dat het bronadres dat hij ziet geen buur in het lokale subnet is.

Lees een storing als een pad, niet als een permissie

Test in een vaste volgorde. Eerst een toegestane dienst van Access Server naar een host in het filiaal, dan dezelfde dienst vanaf een gewone host in het hoofdkantoor, dan de omgekeerde richting als het beleid dat toestaat. Als de eerste slaagt en de tweede faalt, zijn de gepushte routes of de toegangsregels het probleem. Als beide slagen maar er komen geen antwoorden, onderzoek dan het doorsturen in het filiaal en de terugroute bij het hoofdkantoor.

De firewall van de host is de volgende verdachte, want bij gerouteerde toegang ziet de bestemming een hoofdkantoor- of pooladres als bron. Een regel voor het lokale subnet zal niet passen en het pakket wordt weggegooid.

Twee ontwerpen vragen meer. Overlappende prefixen tussen locaties maken de bestemming dubbelzinnig en vereisen hernummering of vertaling, en een geclusterde Access Server vereist dat elke node een werkend pad naar de connector van het filiaal heeft, niet één node die de route houdt. Pas wijzigingen toe via het normale opslaan en bijwerken, verbind de connector opnieuw en verifieer vanaf beide kanten; een volledige herstart van elke machine hoort niet bij de procedure.

De site-to-site-tutorial van Access Server noemt dezelfde instellingen in productvolgorde; het is de moeite waard die één keer te volgen voordat u het ontwerp op uw eigen prefixen aanpast.