OpenVPN bridge, Internet zonder lokale LAN koppeling

[BHQ]

Allicht een leuke, al is dit niet het geschikte tijdstip om met deze dingen bezig te zijn ben ik benieuwd naar jullie inzichten.

Ik wil een OpenVPN netwerk opzetten op basis van bridging, zodat ook (oudere) LAN-games hierover te spelen zijn die gebruik maken van broadcasting. Een plat layer 2 netwerk dus.

Nu heb ik als VPN-server een machine met uplink die ruim genoeg is om veel clients van traffic te voorzien, maar die heeft een publiek IP-adres. Zomaar even een tunneltje hieraan 'koppelen' zoals in de OpenVPN handleiding lijkt mij niet helemaal de bedoeling. De machine heeft enkel een eth0 die direct aan het internet hangt.

De bedoeling is dus dat de clients een IP krijgen uit de pool vanaf de server. Internet over de tunnel moet ook mogelijk zijn. Wellicht is het beter om de clients van losse profielen te voorzien waarbij de gateway wel al dan niet aanstaat. In een situatie waar poorten dichtzitten en alles over de VPN moet gaan, de gateway 'aan', bij een simpel spelletje de gateway 'uit'. Het lijkt mij dat dit moet kunnen, iemand corrigeer mij als dat niet zo is

Nu heb ik twee ideëen (of het moet allemaal veel simpeler kunnen):

- Draai op de server een DHCP op de tap interface en NAT vanaf de publieke interface naar de TAP interface. Clients die verbinden met de tunnel krijgen een IP van de DHCP en hebben wel al dan niet internettoegang via de VPN (via de directives in de client-configuratie).

- Een extra TAP interface met non-public IP op de server waarheen geNAT is vanaf de publieke interface, en die weer gebridged is aan de TAP interface van OpenVPN. Op deze manier zou de ingebouwde IP-pool van OpenVPN gebruikt moeten kunnen worden en is er alsnog internettoegang via de VPN (wederom, bepaald door de client directives).

Dit is allemaal puur uit interpretatie van de OpenVPN manual, die er vanuit gaat dat je een TAP bridged met een andere interface.

Denk ik nu onwijs moeilijk op dit late tijdstip, of zijn het logische opties?

[ Voor 4% gewijzigd door BHQ op 16-07-2010 01:58 ]

[Rudy]

Misschien niet voor bridging gaan, maar voor routing?

[BHQ]

Rudy schreef op vrijdag 16 juli 2010 @ 01:36:
Misschien niet voor bridging gaan, maar voor routing?

Nope, want sommige games die ook over de VPN moeten gaan zijn afhankelijk van broadcasts over het netwerk. En wie weet wat voor archeologische opgraving er komt die over IPX/SPX gaat (ja, dat gaat blijkbaar wel over een tap interface )

Situatieschets:
- Alles moet over de VPN heen kunnen gaan, denk aan broadcasts e.d.
- Clients moeten eventueel via de VPN server op internet kunnen (aan de hand van de config op de client)
- Server deelt IP's uit aan de VPN clients

Ik denk ongetwijfeld *veel* te moeilijk, logischer zou zijn op de server te NATten van de eth0 naar de tap interface en daarop gewoon de 'OpenVPN dhcp' te draaien (de ingebakken dhcp server). Maar enige clue is welkom

[Erik Jan]

Draai gewoon 2 openvpn server instances, 1 voor de virtuele LAN party en 1 voor de internet 'proxy'.

Bij OpenVPN zit een handig GUI'tje waarmee men dan van configuratie kan switchen.

[BHQ]

Ik wil de clients in hetzelfde netwerk hebben. Of er moet een manier zijn om beide OpenVPN netwerken ook weer aan elkaar te koppelen..

[blokje1]

Zelf niet getest maar bouw via openvpn een p2p netwerk

Ga even spelen met brctl aan beide kanten, ervanuitgaande dat eth0 je wan kant is, eth1 je lan kant, en tun0 je tunnel device

code:

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tun0
sysctl net.ipv4.ip_forward=1

Hiermee maak je een bridge tussen 2 devices waardoor traffic op eth1 doorgeduwt wordt op tun0, dit zou ipx/spx moeten kunnen (weet ik niet zeker), maar zet in theorie de broadcasts door.

Laat even weten of het werkt.

NB: Let even op de volgende dingen voor beste performance:

• OpenVPN tunnel moet UDP zijn (niet TCP)
• Zet de MTU van je tunnel iets lager als de MTU van je wan interface. (link-mtu in openvpn.conf, moet je misschien even mee spelen, begin ergens rond de 1400 schat ik)
• Om dit trucje te laten werken kan het zijn dat je TAP moet gebruiken in plaats van TUN

[ Voor 1% gewijzigd door blokje1 op 16-07-2010 13:40 . Reden: IP Forwarding aanzetten ]

[BHQ]

blokje1 schreef op vrijdag 16 juli 2010 @ 13:39:
Zelf niet getest maar bouw via openvpn een p2p netwerk

Ga even spelen met brctl aan beide kanten, ervanuitgaande dat eth0 je wan kant is, eth1 je lan kant, en tun0 je tunnel device

code:

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tun0
sysctl net.ipv4.ip_forward=1

Hiermee maak je een bridge tussen 2 devices waardoor traffic op eth1 doorgeduwt wordt op tun0, dit zou ipx/spx moeten kunnen (weet ik niet zeker), maar zet in theorie de broadcasts door.

Laat even weten of het werkt.

Alleen, ik heb enkel een eth0 en die hangt direct aan het internet. Zou ik met een virtuele interface aan de slag moeten ipv een eth0? Kan dit ook een tun/tapje zijn?

NB: Let even op de volgende dingen voor beste performance:

• OpenVPN tunnel moet UDP zijn (niet TCP)

Yep, lijkt me ivm. games ook wel het meest handige om te doen.

• Zet de MTU van je tunnel iets lager als de MTU van je wan interface. (link-mtu in openvpn.conf, moet je misschien even mee spelen, begin ergens rond de 1400 schat ik)

Jep, zulke dingen heb ik al meerdere keren gelezen.

• Om dit trucje te laten werken kan het zijn dat je TAP moet gebruiken in plaats van TUN

Dat weet ik wel zeker, tap = bridge

[blokje1]

Jarpse schreef op vrijdag 16 juli 2010 @ 14:12:
[...]


Alleen, ik heb enkel een eth0 en die hangt direct aan het internet. Zou ik met een virtuele interface aan de slag moeten ipv een eth0? Kan dit ook een tun/tapje zijn?

NB: Let even op de volgende dingen voor beste performance:

Begrijp ik nu goed dat je 2 workstations aan elkaar gaat knopen en dat er voor de rest geen networking te pas komt, dan zouden 2 tap devices (1 op ieders) genoeg moeten zijn, gebruik iets van 10.0.0.1/30 aan de ene kant en 10.0.0.2/30 aan de andere kant, dan heb je een directe p2p link tussen beide machines.

[...]

Yep, lijkt me ivm. games ook wel het meest handige om te doen.

[...]

Niet alleen voor games;) Anders ga je TCP packets in TCP packets verstoppen waardoor je dubbele ACK's gaat sturen. Eentje voor het TCP pakket en andere voor het pakket in het pakket wat extra pakketten veroorzaakt en waardoor je snelheid drastisch omlaag gaat. Gezien UDP geen 'retry's' kent heb je daar geen last van. En als er toch TCP in zit wordt packetloss automatisch via je tun/tap devices opgevangen om het even symplistisch te houden.

Jep, zulke dingen heb ik al meerdere keren gelezen.

[...]

Dat weet ik wel zeker, tap = bridge

En zo leer ik ook weer eens iets

[BHQ]

blokje1 schreef op vrijdag 16 juli 2010 @ 15:08:
[...]


Begrijp ik nu goed dat je 2 workstations aan elkaar gaat knopen en dat er voor de rest geen networking te pas komt, dan zouden 2 tap devices (1 op ieders) genoeg moeten zijn, gebruik iets van 10.0.0.1/30 aan de ene kant en 10.0.0.2/30 aan de andere kant, dan heb je een directe p2p link tussen beide machines.

Hmm, opnieuw:

VPN endpoint = server met enkel een public IP adres (dedicated server met veel dataverkeer, vandaar). Daar komen meerdere clients op, en deze moeten via de VPN eventueel ook op internet kunnen (lokale gateway op de client wordt overruled, kan dat in de client config ingesteld worden?)

Volg je 'm een beetje?

Internet > VPN <> Clients

[blokje1]

Jarpse schreef op vrijdag 16 juli 2010 @ 15:16:
[...]

Hmm, opnieuw:

VPN endpoint = server met enkel een public IP adres (dedicated server met veel dataverkeer, vandaar). Daar komen meerdere clients op, en deze moeten via de VPN eventueel ook op internet kunnen (lokale gateway op de client wordt overruled, kan dat in de client config ingesteld worden?)

Volg je 'm een beetje?

Internet > VPN <> Clients

Ja ik snap, kijk dan praat je over meerdere tun/tap devices die je wil bridgen, dus in het geval van je server heb je dan een berg tunnels (bijv. tap0, tap1, tap2, tap3). in dat geval zou je het volgende kunnen doen (en gebruik hier up en down scripts voor aan de serverkant). En dan ga ik ervanuit dat je op je server meerdere p2p connecties gaat opzetten.

kijk eens naar brctl dus.

brctl addbr br0

Tap0 - UP:
brctl addif br0 tap0

Tap0 - DOWN:
brctl delif br0 tap0

[Onno]

Jarpse schreef op vrijdag 16 juli 2010 @ 01:30:
- Draai op de server een DHCP op de tap interface en NAT vanaf de publieke interface naar de TAP interface. Clients die verbinden met de tunnel krijgen een IP van de DHCP en hebben wel al dan niet internettoegang via de VPN (via de directives in de client-configuratie).

Dit lijkt me gewoon de oplossing, en dat kan ook nog wel zonder DHCP-server: OpenVPN kan zelf wel ip's naar de clients pushen, ook dynamisch uit een pool als je dat wilt.

Een Linux-bridge of meerdere tap-interfaces voegt daar weinig nuttigs aan toe. Bridgen doet OpenVPN zelf al wel tussen de verschillende clients, en voor internet-toegang is bridgen geen oplossing.

[BHQ]

Onno schreef op vrijdag 16 juli 2010 @ 16:59:
[...]


Dit lijkt me gewoon de oplossing, en dat kan ook nog wel zonder DHCP-server: OpenVPN kan zelf wel ip's naar de clients pushen, ook dynamisch uit een pool als je dat wilt.

Een Linux-bridge of meerdere tap-interfaces voegt daar weinig nuttigs aan toe. Bridgen doet OpenVPN zelf al wel tussen de verschillende clients, en voor internet-toegang is bridgen geen oplossing.

Hmm, dit zit in de denkrichting die logisch zou moeten zijn Gewoon niet de interfaces bridgen dus, maar enkel NATten naar de tap interface.

-edit- Hm, de server moet zelf ook deel uitmaken van de VPN. Ik heb nu een testsituatie maar de server zit zelf niet in het netwerk als ik kijk met bijvoorbeeld Fing.

Heb nog geen losse configuraties gedaan met tun/tapjes, enkel openvpn gestart met m'n config.

[ Voor 17% gewijzigd door BHQ op 16-07-2010 22:27 ]

[BHQ]

Ok, even een kick.

Met Linux clients en Windows machines met de 'text-mode' VPN client werkt alles prima.

Nu wil ik echter de VPN client gaan gebruiken voor de Windows clients, maar dit gaat niet helemaal volgens verwachting.

Bij het toevoegen van een VPN-profiel krijg ik de volgende error:

exceptions.UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

Vervolgens, in de client, als ik een mouse over doe over het profiel in de VPN client, krijg ik het volgende te zien:

This is a static profile that will connect to %S@%S

Je zou zeggen dat de client moeite heeft met het parsen van de configuratie. Ik heb de configuratie op een Linux-machine gemaakt en over geSCP't waarbij de UnicodeEncodeError wegvalt, maar het tweede probleem blijft en de VPN verbind dan ook niet. Ook heb ik geprobeerd het bestand opnieuw op te slaan in Unicode / UTF-8 / ANSI maar ook dit lijkt geen verschil maken.

Iemand een helder moment? Tot dusverre nog geen ander kunnen vinden met eenzelfde probleem..

Meest recente client op elke PC, python library is dezelfde.

[Pumbaa82]

Ik wil een OpenVPN netwerk opzetten op basis van bridging, zodat ook (oudere) LAN-games hierover te spelen zijn die gebruik maken van broadcasting. Een plat layer 2 netwerk dus.

Als ik dit lees in de start post, zou ik zeggen hamachi ?

[BHQ]

Pumbaa82 schreef op woensdag 21 juli 2010 @ 16:20:
[...]


Als ik dit lees in de start post, zou ik zeggen hamachi ?

Been there, done that. Hamachi netwerkjes opzetten is niet leerzaam.