Twee serviceadressen op één OpenVPN-client: iroute en lo

De applicatie antwoordt op zijn tunneladres, en het adres dat u ervoor documenteerde leidt nergens heen. Niets in het OpenVPN-log klaagt, de peer verschijnt als verbonden en de hub vermeldt precies één client. De leemte is dat een tweede adres op een client twee afzonderlijke feiten zijn: de host moet het bezitten, en de hub moet weten welke peer het bezit. Behandel het ene zonder het andere en het verkeer sterft bij de hub of komt aan zonder route naar huis.

Het alias is lokaal, het eigendom is op afstand

Een tunneladres wordt onderhandeld, dus beide uiteinden leren het tijdens de handshake. Een extra serviceadres wordt helemaal niet onderhandeld, daarom verandert het toevoegen ervan op zichzelf niets aan de hub. De client kan het adres meteen bezitten en de server stuurt dat verkeer nog steeds over zijn standaardpad of gooit het weg. Er moeten twee records worden aangemaakt, op twee verschillende plaatsen.

Op de client hoort het adres bij de host, en loopback is de natuurlijke thuisbasis voor een service-identiteit die nooit op een fysieke verbinding mag verschijnen. Op de hub is de peer-naar-prefix-toewijzing een aparte verklaring die alleen de server leest. Geen van beide records impliceert het andere.

Houd de twee bereiken ook in uw notities gescheiden. Adressen in een voorbeeld zijn documentatiewaarden, en ze laten overlappen met een echt LAN is de snelste manier om een werkende opstelling kapot te laten lijken.

Voeg het adres blijvend toe op de client

Plaats het serviceadres op loopback met een hostprefix, zodat de host het als lokale invoer behandelt en niet als een subnet dat bereikt moet worden. ip address add 10.66.0.10/32 dev lo doet dat voor één adres, en het commando herhalen voor een tweede adres modelleert twee diensten.

Voer dat uit als een eenmalige test en verplaats het daarna naar wat de netwerkconfiguratie van de host bezit, want een toevoeging tijdens runtime verdwijnt bij een herstart en duplicaten hopen zich op tussen herverbindingen. Een systemd-eenheid die na het netwerk is geordend is één optie, en een netwerkbeheerder van de distributie is een andere. Wat u ook kiest, het adres moet bestaan voordat de applicatie zich bindt, anders komt de dienst op de verkeerde socket op. Verifieer met ip address show dev lo na een herstart en niet na het handmatige commando.

Binden is een beslissing los van adressering. Een applicatie die op elk adres luistert, accepteert verkeer op interfaces die u nooit bedoelde, dus wijs hem naar het specifieke serviceadres. Dan heeft het lokale invoerbeleid iets precies om mee te matchen.

Eis het op in het CCD-bestand dat de hub echt leest

Op de server gaat de eigendomsverklaring in het bestand per client dat door de geauthenticeerde gemeenschappelijke naam wordt gekozen, in de map die door client-config-dir wordt genoemd. De regel is iroute 10.66.0.10 255.255.255.255, één per adres, en hij vertelt de server welke peer verkeer voor die bestemming moet ontvangen.

Twee details breken dit stil. De bestandsnaam moet overeenkomen met de naam die de server echt gebruikt, en die verschilt wanneer username-as-common-name in het spel is. En iroute werkt alleen in TUN-modus met een geconfigureerde clientconfiguratiemap, dus dezelfde regel doet niets in een gebrugde implementatie. Voeg regels toe aan het bestaande bestand in plaats van het te vervangen, want het kan al een vast adres of push-opties bevatten. De OpenVPN 2.6-referentie documenteert zowel de map als de eigendomsrichtlijn.

De eigen kernel van de hub heeft ook een pad naar die bestemmingen nodig, zodat lokaal gegenereerd verkeer het tunnelproces binnenkomt. route 10.66.0.10 255.255.255.255 in de serverconfiguratie dekt verkeer dat de server zelf maakt, terwijl andere clients push "route 10.66.0.10 255.255.255.255" nodig hebben om de bestemming zelf te leren.

Routering en autorisatie blijven gescheiden. Een gepushte route vertelt een client waar pakketten heen moeten en verleent niets; de dienst moet de beller nog steeds op zijn eigen voorwaarden accepteren.

Controleer het invoerbeleid en het antwoordpad

Een pakket dat aan het alias is geadresseerd, komt bij de bezittende host aan als lokale invoer, dus de vraag is of de lokale firewall die bron en poort toestaat. Sta de specifieke servicepoort uit het VPN-bronbereik toe in plaats van het hele adres te openen.

Antwoorden hebben een pad terug naar de beller nodig. Voor een beller in de normale tunnelpool bestaat dat pad al, omdat het tunnelapparaat het draagt. Een beller achter een ander gerouteerd netwerk heeft ook de retourroute van dat netwerk nodig, en hier verliezen asymmetrische opstellingen pakketten.

Let op een tweede luisteraar op dezelfde poort die aan een ander adres is gebonden, want de kernel levert aan de socket die overeenkomt en de resultaten lijken willekeurig. Controleer met ss -lntp en bevestig dat het gebonden adres het servicealias is. Source-NAT is hier niet nodig, en het toevoegen verbergt de identiteit van de beller waarvan uw logs afhangen.

Test adressen en eigendom apart

Test in twee stappen. Bevestig eerst dat de bezittende host de dienst op zijn alias vanaf zichzelf kan bereiken, wat bind- en firewallproblemen van routering scheidt. Test daarna vanaf een echte VPN-beller met de authenticatie van de applicatie zelf. Wanneer het eerste slaagt en het tweede mislukt, zit het ontbrekende stuk aan de hubkant.

Controleer ook de faalmodi die een verbinding overleven: het alias blijft toegewezen wanneer de tunnel omlaag is, en de hub behoudt zijn route wanneer de peer ontbreekt. Geen enkel object bewijst alleen dat de dienst bereikbaar is, en daarom verslaat de tweestapstest één ping vanaf een laptop.