OpenVPN via TCP en UDP vanaf één host aanbieden
Eén proces bindt vóór 2.7 één transport. Vergelijk een overbrugd TAP-paar, twee TUN-subnetten en een gedeelde pool, en koppel daarna elk profiel aan zijn eigen listener.
Netwerken die alleen TCP 443 toestaan, bestaan naast netwerken die UDP probleemloos doorlaten, en één server moet beide bedienen. Een profiel met proto udp antwoordt de tweede groep en faalt bij de eerste, en dezelfde configuratie aanpassen om proto tcp te zeggen maakt geen tweede listener. De richtlijn kiest één transport voor één proces. Al het andere volgt uit die beperking.
Of je draait meer dan één proces, of je draait een versie die meerdere sockets tegelijk kan binden.
Eén proces bindt vóór 2.7 één transport
Het community-OpenVPN bindt de socket die proto beschrijft, en die richtlijn kiest één transport voor het exemplaar. TCP en UDP zijn gescheiden stacks, dus hetzelfde poortnummer kan tegelijk door beide bezet zijn, maar niet door één proces. De 2.6-lijn geeft je daarom één transport per daemon. OpenVPN 2.7 verwijderde die beperking voor servers, die meerdere sockets kunnen binden via meerdere --local-instructies in één proces.
Controleer de versie voordat je rond een van beide antwoorden ontwerpt, want de 2.7-opstelling is een ander operationeel model met eigen configuratiesyntaxis. Een gids die voor 2.6 is geschreven, beschrijft twee processen ook als hij dat niet zegt.
Drie manieren om twee exemplaren te draaien
Met TAP-interfaces draai je één exemplaar per transport en overbrug je de twee tap-apparaten op de host. Beide klantsets belanden in hetzelfde broadcastdomein, waardoor één adrespool ze kan dekken en broadcastafhankelijke protocollen blijven werken. Met TUN is overbruggen niet beschikbaar, dus de eenvoudigste splitsing geeft elk exemplaar zijn eigen subnet en laat routing de twee klantsets gescheiden houden. Een derde optie houdt één pool door elk exemplaar een learn-address-script te laten aanroepen dat een /32-route voor de client installeert via het apparaat van dat exemplaar.
Die derde opstelling is degene waar mensen om vragen en degene die de meeste zorg vereist, omdat het script deel wordt van het datapad en de gebeurtenissen toevoegen, bijwerken en verwijderen correct moet afhandelen.
| 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 |
Houd de twee exemplaren gescheiden
Elk exemplaar heeft ook een aparte poort of een apart adres nodig, een apart statusbestand en een aparte logbestemming. Twee daemons die naar hetzelfde statusbestand schrijven, produceren uitvoer die tijdens een incident niet te lezen is, en juist dan heb je die nodig. Als een tweede exemplaar een specifiek adres bindt, moet dat adres op de host bestaan wanneer het proces start; anders stopt het met een bindfout voordat het iets over sleutels zegt.
Noem de units en de profielen zodat het transport duidelijk is uit de bestandsnaam. De volgende operator zou geen configuratie hoeven te openen om te weten welke TCP is.
Koppel het profiel aan de listener
Een server die proto tcp draait, verwacht een klantprofiel met proto tcp-client, en een profiel dat nog proto udp bevat, loopt bij die listener vast op een time-out zonder fout waar de gebruiker iets mee kan. Houd twee profielen aan als de uitrol beide transporten biedt, en label ze zodat support weet welke is geprobeerd. Het poortnummer alleen beschrijft het transport niet.
Firewallregels volgen dezelfde splitsing: een regel voor UDP 1194 zegt niets over TCP 1194, en een regel voor één adres dekt de andere listener niet.
Lees eerst het beeld van de server
Begin met ss -lntup op de server en bevestig dat zowel een TCP- als een UDP-listener verschijnt. Verbind daarna één client van elk soort en controleer de statusuitvoer op twee vermeldingen met verschillende adressen. Als de sockets bestaan en er komt geen client, weigeren het pad of de firewall pakketten voordat de daemon ze ziet.
Een socket die nooit verschijnt is een configuratie- of bindprobleem, en een socket die verschijnt maar nooit een verbinding logt is een filterprobleem. Die twee zien er vanaf de client identiek uit, en daarom komt het eigen beeld van de server eerst. Onthoud dat TCP head-of-line-blokkering kent, dus het aanbieden ervan is een bereikbaarheidsmaatregel en geen verbetering voor clients met een schoon UDP-pad.