Eén Pi, twee OpenVPN-instanties: wat elke unit leest

Tel de OpenVPN-processen voordat je een profiel aanraakt. Een Pi die roaminggebruikers toelaat en tegelijk een upstreamdienst belt, draait twee daemons, en elk daarvan leest een configuratiebestand dat wordt gekozen door de instantienaam die je hebt getypt. De sjablonen van het pakket geven elke daemon vervolgens een eigen werkmap, een eigen runtime-statusbestand en een eigen tunnelapparaat. Doe je die splitsing verkeerd, dan breng je een avond door met het wijzigen van een correcte instelling in een bestand dat het draaiende proces nooit opent.

Elke instantienaam kiest zijn eigen bestand

In de unitbestanden die met OpenVPN 2.6 worden meegeleverd, dragen de startargumenten een instantieplaatshouder die wordt gevuld met de tekst na het @-teken. Het serversjabloon draait vanuit de serverconfiguratiemap en lost zijn argument op tegen %i.conf daar, terwijl het clientsjabloon hetzelfde doet vanuit de clientmap. Dus [email protected] leest admits.conf in de servermap en [email protected] leest uplink.conf in de clientmap, en geen van beide namen heeft enige betekenis in de andere map.

Controleer de toewijzing op de machine in plaats van aan te nemen dat het pakket de upstream-standaardwaarden heeft behouden. Een drop-in van de distributie mag de werkmap of het configuratieargument volledig vervangen.

systemctl cat [email protected]
systemctl cat [email protected]

Lees de WorkingDirectory-regel en het configuratieargument in die uitvoer, want de ingeschakelde unit is het enige dat bepaalt welk bestand wordt geladen. Een drop-in die --config aan ExecStart toevoegt, wint van het sjabloon zelfs wanneer het sjabloonpad er goed uitziet. Vraag naar de fragment- en drop-in-paden wanneer je wilt weten of een lokale overschrijving meespeelt. Als beide rollen naar één bestand verwijzen, heb je één proces dat zowel server als client probeert te zijn, en de latere optie in dat bestand wint stilletjes.

Lokaal transport en doorgestuurde payload raken verschillende hooks

De versleutelde verbinding van de server met elke roaminggebruiker wordt op de Pi zelf gegenereerd, dus de buitenste antwoorden gaan via de lokale uitvoerhook naar buiten. De verbinding van de client met zijn upstreampartner is ook lokaal gegenereerde uitvoer, ook al bereikt die een extern netwerk. Doorgestuurde payload is de derde categorie, en de kernel koppelt die pas nadat hij al een uitgaand apparaat voor het pakket heeft gekozen.

Een regel die in een forward-keten overeenkomt met een uitgaande interface kan een pakket toestaan of laten vallen dat routing al aan die interface heeft toegewezen, maar hij kiest de interface nooit. Wanneer één host de ene tunnel beëindigt en de andere begint, zijn het beleid dat gebruikerspayload de upstreamtunnel in stuurt en het beleid dat de eigen versleutelde antwoorden van de Pi beschermt twee aparte beslissingen. Ze belanden toevallig op dezelfde fysieke NIC, en daarom worden ze verward.

Dat onderscheid verklaart een veelvoorkomende halve fout. Gebruikers verbinden, de handshake voltooit, en hun verkeer vertrekt toch de verkeerde kant op, omdat de handshake lokaal was en de payload forward en slechts één van de twee ooit werd getest.

Een geïmporteerde route kan de antwoorden aan je gebruikers inslikken

De beveiligingsinstelling van het clientprofiel bepaalt wat de upstream in de routetabel van de Pi mag duwen, en een brede omleiding is de optie die een werkende host met dubbele rol in een kapotte verandert. Als de geduwde route de openbare adressen van roaminggebruikers dekt, kunnen de antwoorden die de server naar hen genereert de nieuwe route volgen de upstreamtunnel in in plaats van via de underlay naar buiten te gaan. Mensen bevestigen vaak dat de tunnel naar de provider nog werkt en stoppen daar, omdat dat verkeer het eigen transport van de tunnel is en blijft stromen terwijl al het andere zich verkeerd gedraagt.

Beleid op basis van bron of mark is hoe de twee stromen gescheiden blijven. De Linux-mark-optie van OpenVPN voorziet de eigen versleutelde pakketten van een daemon van een firewallmark, die een routeringsregel vervolgens naar een aparte tabel kan sturen. Bronadressen werken net zo goed wanneer de buitenste antwoorden van de server altijd van één underlayadres vertrekken. Beide benaderingen vereisen geldige routes in de tabel die ze selecteert en een uitzondering voor het endpoint van de provider, anders komt de tunnel zelf niet meer op.

Vraag de kernel welk pad een antwoord werkelijk zou nemen voordat je een regel schrijft. De adressen hieronder zijn plaatshouders voor een underlayadres van de Pi en het openbare adres van één roaminggebruiker.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifieer de splitsing en stop dan één rol tegelijk

Test drie stromen apart, want een werkende handshake bewijst niets over de andere twee. Accepteer een nieuwe inkomende verbinding, stuur één toegestane toepassing via de upstreamuitgang en bevestig dat beide processen hun eigen partners nog bereiken.

Stop dan de clientrol en kijk wat de serverrol behoudt. Dit is de goedkoopste manier om een route- of markregel te vinden die voor één instantie bedoeld was en op beide is toegepast.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Wat je wilt zien is dat de listener nog gebonden is, het tunnelapparaat nog aanwezig is en het log vrij is van nieuwe fouten terwijl de clientrol uit staat. Als het stoppen van de client ook de antwoorden van de server aan bestaande gebruikers afsnijdt, delen de twee rollen iets dat tot één van hen beperkt had moeten blijven. Noteer welke instantie, welk configuratiebestand en welke stroomeigenaar elke wijziging raakte, want de volgende persoon die deze host debugt, herhaalt anders dezelfde ontdekking vanaf nul.