Köra OpenVPN över TCP och UDP från en enda värd
En process binder en transport före 2.7. Jämför ett bryggat TAP-par, två TUN-subnät och en delad pool och matcha sedan varje profil mot sin lyssnare.
Nätverk som bara tillåter TCP 443 finns sida vid sida med nätverk som släpper igenom UDP utan problem, och en server måste betjäna båda. En profil med proto udp svarar den andra gruppen och misslyckas mot den första, och att redigera samma konfiguration till att säga proto tcp skapar ingen andra lyssnare. Direktivet väljer en transport för en process. Allt annat följer av den begränsningen.
Antingen kör du mer än en process, eller så kör du en version som kan binda flera sockets samtidigt.
En process binder en transport före 2.7
Community-OpenVPN binder den socket som proto beskriver, och det direktivet väljer en enda transport för instansen. TCP och UDP är separata stackar, så samma portnummer kan vara upptaget av båda samtidigt, men inte av en process. 2.6-linjen ger dig därför en transport per daemon. OpenVPN 2.7 tog bort den begränsningen för servrar, som kan binda flera sockets via flera --local-satser i en process.
Kontrollera versionen innan du designar kring något av svaren, eftersom 2.7-uppsättningen är en annan driftsmodell med egen konfigurationssyntax. En guide skriven för 2.6 beskriver två processer även när den inte säger det.
Tre sätt att köra två instanser
Med TAP-gränssnitt kör du en instans per transport och bryggar de två tap-enheterna på värden. Båda klientgrupperna hamnar i samma broadcastdomän, vilket låter en adresspool täcka dem och håller broadcastberoende protokoll igång. Med TUN är bryggning inte tillgänglig, så den enklaste uppdelningen ger varje instans ett eget subnät och låter routingen hålla de två klientgrupperna åtskilda. Ett tredje alternativ behåller en pool genom att låta varje instans anropa ett learn-address-skript som installerar en /32-rutt för klienten via den instansens enhet.
Den tredje uppsättningen är den folk frågar efter och den som kräver mest omsorg, eftersom skriptet blir en del av datavägen och måste hantera händelserna lägg till, uppdatera och ta bort korrekt.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Håll de två instanserna åtskilda
Varje instans behöver också en egen port eller adress, en egen statusfil och ett eget loggmål. Två daemoner som skriver till samma statusfil producerar utdata som inte går att läsa under en incident, och det är precis då du behöver den. Om en andra instans binder en specifik adress måste den adressen finnas på värden när processen startar; annars avslutas den med ett bindfel innan den säger något om nycklar.
Namnge enheterna och profilerna så att transporten är uppenbar från filnamnet. Nästa operatör ska inte behöva öppna en konfiguration för att veta vilken som är TCP.
Matcha profilen mot lyssnaren
En server som kör proto tcp förväntar sig en klientprofil med proto tcp-client, och en profil som fortfarande har proto udp mot den lyssnaren går ut på tid utan ett fel som användaren kan agera på. Behåll två profiler om utrullningen erbjuder båda transporterna, och märk dem så att supporten vet vilken som provades. Enbart portnumret beskriver inte transporten.
Brandväggsregler följer samma uppdelning: en regel för UDP 1194 säger ingenting om TCP 1194, och en regel för en adress täcker inte den andra lyssnaren.
Läs serverns egen bild först
Börja med ss -lntup på servern och bekräfta att både en TCP- och en UDP-lyssnare syns. Anslut sedan en klient av varje slag och kontrollera statusutdata för två poster med olika adresser. Om socketarna finns och ingen klient kommer dit avvisar vägen eller brandväggen paketen innan daemonen ser dem.
En socket som aldrig syns är ett konfigurations- eller bindproblem, och en socket som syns men aldrig loggar en anslutning är ett filtreringsproblem. De två ser likadana ut från klienten, och därför kommer serverns egen bild först. Tänk på att TCP bär head-of-line-blockering, så att erbjuda det är en åtkomlighetsåtgärd och inte en uppgradering för klienter med en ren UDP-väg.