Dotaz: OpenVPN a Herní servery

[Petr Maleček]

Mám OpenVPN server a několik desítek klientů. Používám protokol UDP, vlastní DHCP a DNS server + WINS přes sambu.

OpenVPN klientům odešle IP adresu přes DHCP (dhcpd3), adresu DNS (bind9) a adresu WINS (samba). Server má IP 10.0.10.1 a klienti 10.0.10.10-100. Adresa DHCP, DNS, WINSu je IP serveru, takže 10.0.10.1 (zde ty služby běží).

Vše funguje zdá-se jak má, ovšem je tu jeden technický nedostatek.

Jelikož se jedná o síť víceméně hráčů CS, HL, WoW, W3, wic ..., tak se narazilo na problém, a to takový, že když někdo založí hru, tak není v síti viditelná, přitom třeba počítače jsou v místní síti vidět, PING funguje, sdílení taky, tisk taky.

Pokavad se připojím třeba příkazem connect IP, tak se bez problémů připojím, ale potřeboval bych trošku nakopnout, kde hledat příčinu toho, že není vidět v seznamu her ten, kdo už hru založil a musíme se připojovat manuálně.

Žádné ROUTY nepoužívám, možná bude problém právě to, ale nenapadá mi jediný důvod, proč bych je měl používat, do vnitřní sítě klienty tahat nechci.

Díky moc za nakopnutí !!

Odpovědi

[Milan Beneš]

Zdravím,

v routování nejspíš problém nebude, nemělo by ani být potřeba v tomto případě nějak řešit. Pokud ovšem používáte routovanou VPN (tunel, v konfiguráku je uvedeno "dev tun"), pak je příčina problémů zřejmá - přes ppp neproleze broadcast, kterým si počítače osahají své okolí, aby zjistily, kde který herní server běží.

[Petr Maleček]

Děkuji za odpověď. Nepoužívám TUN, ale TAP.

[Petr Maleček]

Řekl bych, že jsem to právě vyřešil pomocí bcrelay -i tap0 -o tap0 -d.

[Petr Maleček]

Tak bohužel, broadcastu se nějak nedočkávám :(

[Milan Beneš]

Napadá mě - běží tap rozhraní na serveru v promiskuitním režimu? Mohlo by to pomoct.

[Petr Maleček]

To netuším, jak bych to mohl poznat ? Stav je takový, že WINS počítače rozšiřuje, takže se v síti vidíme všichni (především PC s Vistou a Win7), ale hry se krom Bulánků navzájem nevidí.

Další problém, na který jsem narazil je ten, že když na serveru pingnu broadcast (ping -b 10.0.10.255), tak nemám žádnou odezvu. Když pingu na klientských stanicích 10.0.10.0 nebo 255, tak první ohlásí neplatný cíl a druhý bez odezvy (packet loss).

Řekl bych, že bude příčina problémů právě zde. Ovšem netuším, jak řešit. Schválně jsem ponechal onen bcreply loopovat z tap0 na tap0 (dočasně replikace broadcastu nevadí, naopak jsem myslel, že pomůže), ovšem to pomáhá pouze v tom, že se počítače v síti najdou "rychleji". Hry ani prd, krom Bulánků, ti se vidí.

 

[Milan Beneš]

ifconfig tap0

jinak je otázka, odkud si WINS bere data o počítačích a co slouží jako WINS server. Pokud je to Samba, pak se broadcast vůbec nemusí uplatnit pro zaplnění WINS databáze.

[Petr Maleček]

ifconfig vypíše toto:

tap0      Link encap:Ethernet  HWadr 00:ff:f6:f2:b4:3e
          inet adr:10.0.10.1  Všesměr:10.0.10.255 Maska:255.255.255.0
          inet6-adr: fe80::2ff:f6ff:fef2:b43e/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:7871 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11067 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:100
          RX bytes:1418666 (1.3 MiB)  TX bytes:3176609 (3.0 MiB)

Jako WINS používám Sambu. Počítače s OS WinVista a Win7 se vidí, ovšem počítače s XP (Home/Pro) se nevidí. Broadcast tedy jak už jsem říkal nefunguje (ping -b 10.0.10.255). Na serveru provozuju i DDNS (bind9), ale ten je zatím nakonfigurován tak, že nemá s rozhraním TAP nic společného (běží na eth rozhraní).

WINS databázi jsem vyčistil (vymazal jsem obsah souboru /var/lib/samba/wins.dat), ovšem beze změny. Pouze jsem vyřešil problém, kdy klient měl nějakou IP, pak dostal jinou, ale ping šel stále na tu původní (samozřejmě když jsem dal třeba ping jindra-pc), přes IP neni problém.

Už nad tím trávím skoro druhý den, ale stále jsem nic nevyřešil. Především ten broadcast mě dostává :(

Díky za trpělivost a pomoc.

[cynic_asshole]

A nechceš sem hodit pro jistotu i konfiguráky serveru a klientů? Možná bude zakopaný pes tam. Mě napadlo, jestli máš na serveru direktivu client-to-client, ale nevím, jestli tohleto má nějaký vliv na broadcasty.

[Petr Maleček]

Config serveru:

port 1194
proto udp
dev tap0

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
duplicate-cn
mode server
tls-server
client-to-client
ifconfig 10.0.10.1 255.255.255.0
#server 10.0.10.0 255.255.255.0
#server 10.0.10.0 255.255.255.0

#push "route 10.0.10.0 255.255.255.0"
push "dhcp-option DNS 10.0.10.1"
push "dhcp-option DOMAIN parani"
push "dhcp-option WINS 10.0.10.1"

keepalive 10 120
comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn/status.log
log-append  /var/log/openvpn/openvpn.log

verb 3
mute 20

Config klienta:

client
dev tap
proto udp
remote ipadresa 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 3

[Milan Beneš]

No, každopádně přímo v dokumentaci OpenVPN pokrývající bridging:

http://openvpn.net/index.php/ethernet-bridging.html

je fyzické rozhraní na serveru i virtuální TAP rozhraní v promiskuitním režimu.

[cynic_asshole]

A jak to máš řešené na serveru? Je to úplně izolovaná síť, že se na ni z jiné sítě nedostaneš? Nebo je tam v bridgi s něčím

[Petr Maleček]

Ta síť je naprosto izolovaná, bridge žádný.

[Petr Maleček]

Ještě mi napadlo, že by mohla být chyba v routách. Teď mám routy takovéto:

 

 Směrovací tabulka v jádru pro IP
 Adresát         Brána           Maska           Přízn Metrik Odkaz  Užt Rozhraní
 majky           *               255.255.255.255 UH    0      0        0 vif1.0
 wow             *               255.255.255.255 UH    0      0        0 vif2.0
 10.109.184.192  *               255.255.255.192 U     0      0        0 eth0
 10.0.10.0       *               255.255.255.0   U     0      0        0 tap0
 default         router-garfield 0.0.0.0         UG    0      0        0 eth0

Kde rozhraní tap0 nemá žádnou gateway (což je správně) ... bohužel nevím, co je příznak "U" (že by user ?)

[svaca]

Mrkni do FAQ k OpenVPN, tam je jasne napsano: jedes pres bridge (TAP) mas vyssi vykon, ale pak jen same nevyhody.

- nejsou broadcasty - nefunguje tim padem netbios -atd ...

je tam i navod jak to vyresit pomoci samby ...

[Petr Maleček]

Já čtu malinko něco jiného:

Bridging advantages

• Broadcasts traverse the VPN -- this allows software that depends on LAN broadcasts such as Windows NetBIOS file sharing and network neighborhood browsing to work.
• No route statements to configure.
• Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
• Relatively easy-to-configure solution for road warriors.

Takže mám bridge (TAP) a to je správně. Ovšem studuji ještě tento návod, tak doufám, že se podaří.

[oxymoron]

man route

Flags  Possible flags include
              U (route is up)
              H (target is a host)
              G (use gateway)
              R (reinstate route for dynamic routing)
              D (dynamically installed by daemon or redirect)
              M (modified from routing daemon or redirect)
              A (installed by addrconf)
              C (cache entry)
              !  (reject route)

[Petr Maleček]

Děkuju !

[M_P]

Kdysi jsem mel podobny problem, broadcasty z widli XP nelitaly skrz tap zarizeni, ale pres sitovku a proto se hraci nevideli (I kdyz pingat slo). Myslim ze mi pomohlo nastavit spravne poradi v jakem pristupuji sitove sluzby k adapterum. (Sitova pripojeni -> Upresnit -> Upresnit nastaveni)

M.

[cynic_asshole]

Zkus na serveru nastavit ještě direktivu server
server 10.0.10.0 255.255.255.0

[Petr Maleček]

Takže jsem zkončil u stejného problému, kterým je broadcast. V systému mi prostě nejde ping -b 10.0.10.255, přestože do naší sítě (nikoli VPN) boadcast funguje (odpoví na něj všichni). Už jsem bezradný. TAP0 je správně, IP mam správně, Wins používám, DNS funguje. Ale ping broadcast prostě ne a ne.

[cynic_asshole]

Co na to říká Wireshark? Odejde z toho počítače s Windows ping na broadcast? Ještě zkus poslat routovací tabulku z windows klienta.

[Petr Maleček]

Když dám na serveru ping -b 10.0.10.255, tak na windows klientech přes Wireshark zachytávám toto:

48    21.375716    10.0.10.1    10.0.10.255    ICMP    Echo (ping) request - (z IP 10.0.10.1 - server na 10.0.10.255, což je broadcast IP a IP klienta je 10.0.10.5, takže teoreticky broadcast sítí prochází, ale už se nevrací odezva, protože počítač na ten ping neodpovídá)

A velmi často se tam zobrazuje červeně toto:

62    27.988683    10.0.10.1    224.0.0.251    MDNS    Standard query PTR 108.44.99.38.in-addr.arpa, "QM" question (z 10.0.10.1 na 224.0.0.251, což nevím co je za IP, žádnou takovou v síti nemám(e)).

Občas tam zahlédnu i CUPS (ipp), takže broadcast evidentně funguje (vysílá se), ale příjem nefunguje (odpověď).

[Petr Maleček]

Route tabulka obsahuje tuto hrůzu (ve WIN klientovi):

IPv4 Směrovací tabulka
===========================================================================
Aktivní směrování:
         Cíl v síti   Síťová maska            Brána        Rozhraní Metrika
          0.0.0.0          0.0.0.0   10.109.184.193   10.109.184.220     30
        10.0.10.0    255.255.255.0       Propojené         10.0.10.7    286
        10.0.10.7  255.255.255.255       Propojené         10.0.10.7    286
      10.0.10.255  255.255.255.255       Propojené         10.0.10.7    286
   10.109.184.192  255.255.255.192       Propojené    10.109.184.220    286
   10.109.184.220  255.255.255.255       Propojené    10.109.184.220    286
   10.109.184.255  255.255.255.255       Propojené    10.109.184.220    286
        127.0.0.0        255.0.0.0       Propojené         127.0.0.1    306
        127.0.0.1  255.255.255.255       Propojené         127.0.0.1    306
  127.255.255.255  255.255.255.255       Propojené         127.0.0.1    306
     192.168.88.0    255.255.255.0       Propojené      192.168.88.1    276
     192.168.88.1  255.255.255.255       Propojené      192.168.88.1    276
   192.168.88.255  255.255.255.255       Propojené      192.168.88.1    276
    192.168.174.0    255.255.255.0       Propojené     192.168.174.1    276
    192.168.174.1  255.255.255.255       Propojené     192.168.174.1    276
  192.168.174.255  255.255.255.255       Propojené     192.168.174.1    276
        224.0.0.0        240.0.0.0       Propojené         127.0.0.1    306
        224.0.0.0        240.0.0.0       Propojené      192.168.88.1    276
        224.0.0.0        240.0.0.0       Propojené     192.168.174.1    276
        224.0.0.0        240.0.0.0       Propojené         10.0.10.7    286
        224.0.0.0        240.0.0.0       Propojené    10.109.184.220    286
  255.255.255.255  255.255.255.255       Propojené         127.0.0.1    306
  255.255.255.255  255.255.255.255       Propojené      192.168.88.1    276
  255.255.255.255  255.255.255.255       Propojené     192.168.174.1    276
  255.255.255.255  255.255.255.255       Propojené         10.0.10.7    286
  255.255.255.255  255.255.255.255       Propojené    10.109.184.220    286
===========================================================================
Trvalé trasy:
  Žádné

[M_P]

Pokud v tom nema prsty nejakej firewal na tom win stroji, tak tim wiresharkem zkus zjistit jestli ping reply neodchazi pres jinej interface...

[Petr Maleček]

Firewall vypnut (dočasně), pakety odcházejí přes Win32-TAP zařízení.

[M_P]

Vzdyt jsi psal ze odpoved na ping ze stanice neodchazi....

[cynic_asshole]

Nechceš poslat celej dump z wiresharku?

[Petr Maleček]

Zítra zašlu. Každopádně nevím co si mám myslet, jelikož WINS funguje (vidím všechny aktivní počítače v síti, dokonce když nějaký z nich vypnu, tak po chvíli zmizí ze seznamu), hra Bulánci funguje (najdou se), sdílení i PING prochází.

Ještě jsem zapomněl dodat (možná je to nepodstatné), že nepoužívám interní DHCP (v OpenVPN), ale DHCP3 a BIND9.

Mám to kvůli výpisu uživatelů, který jsem si udělal ( vpn.pmalecek.cz ).

[Milan Beneš]

Jak tak pozoruju ty výpisy, tak ta VPN se mi zdá, že vůbec není zkonfigurovaná pro bridging, spíš to vypadá jako routovaná VPN, kde se místo tun používá tap. Správně by to mělo vypadat tak, že tap rozhraní jak na klientech tak i na serveru by mělo být zbridgované s odpovídajícím fyzickým rozhraním na daném stroji a IP adresy by měly být přidělovány až vytvořenému bridgi. Viz. dokumentace, na kterou jsem již odkazoval.

[cynic_asshole]

V tom by mohl být ten zakopaný pes. Jak se to chová, když použiješ interní DHCP?

[Petr Maleček]

Úplně stejně, pouze má klient pokaždé jinou IP, když se připojí. Každopádně já NECHCI žádný most, protože nechci propojovat dvě sítě. Chci prostě samostatnou síť, která nebude mít s tou druhou nic společného.

Nebo to mám snad chápat tak, že i přesto musí být bridge ? V tom případě nechápu, nač dvě rozhraní ? K čemu mi je to dobré ? Přece když stavím reálnou síť, tak nepotřebuju v serveru dvě síťovky, abych mohl klientům přidělovat IPčka a DNS názvy.

[Petr Maleček]

Zapojení je zkrátka takové, že mám server a na ten se připojují klienti (včetně mě). U serveru nikdo nesedí, je to prostě komp na půdě.

[cynic_asshole]

Ne, do bridge to dávat nemusíš. A ten OpenVPN se dá nakonfigurovat tak, že klientu přiřadí stejnou IP. Jak jsem psal výš, zkus odkomentovat tu direktivu server, použij interní DHCP a pak napiš, jak se to chová.

[Petr Maleček]

Já jsem to zkoušel s obojím, není v tom vůbec žádný rozdíl, funkčnost stejná. 

Co jsem četl na netu, tak jelikož používám pro všechny stejný certifikát, tak bohužel výsledku, kdy dostane pokaždé klient stejnou IP nelze dosáhnout.

[cynic_asshole]

Aha, ty používáš všude stejný certifikát. Ještě mě napadla jedna věc, na jednom počítači spusť wiresharka a bulánky, založ na něm hru. Na serveru na tom tap0 rozhraní spusť tcpdump, ulož z něj výstup, zatímco budou ti bulánci spuštění, a na druhém počítači spusť taky wireshark. Pak sem pošli všechny tři výstupy. Je divné, že ti Bulánci jdou bez problémů, zatímco ostatní "ticho po pěšině".

[Milan Beneš]

Teď jsou tady ještě dvě otázky:

1) MAC adresy u těch TAP rozhraní jsou pokaždé stejné? tj. jak na klientech tak i na serveru? Pokud se mění, může být taky bordel v arp cache

2) Je potřeba se ujistit, jestli ty herní servery poslouchají opravdu na TAP rozhraní a ne jen na fyzickém ethernetu

[Petr Maleček]

1) Ty MAC adresy jsou stejné do doby, než někdo přeinstaluje systém, nebo OpenVPN (klienta). Už jsem se s tím setkal a bylo potřeba poté "vynulovat" soubor /var/lib/samba/wins.dat.

2) Ono je to dosti zvláštní, chová se do opravdu divně. Včera jsem si chtěl sám zahrát Counter-Strike 1.6 a jen tak jsem se podíval, jestli náhodou někoho neuvidím v LAN Games, že hraje.  A kupodivu měl kámoš z druhé strany republiky založenou hru (člen mojí VPN). Takže broadcast v tu chvýli fungoval (i odemně, zkoušel jsem založit bulánky pro 3 PC a na obou jsem tu síťovou hru okamžitě našel). 

Hodně se situace mění, teď kupříkladu mám problém se seznamem počítačů v síti (WINS), protože když kliknu na Místa v síti a kliknu na zobrazit PC ve skupině, tak dlouho nic a pak mi to vyhodí hlášku, že nemám právo prohlížení. Přitom stačí třeba jenom restartovat SAMBu, nebo OpenVPN a pak tam zase vidím všechny počítače. Z ničeho nic se zase pak vše obrátí a nevidím ani prd (vůbec nikoho - a to je tak u všech). Když vidím já, vidí všichni. Když nevidím já, nevidí nikdo).

Včera když jsem zkoušel to CSko, tak byly počítače v síti vidět, CSko běželo, Bulánci taky. Dnes jsem zapnul počítač, nevidím žádný PC, Bulánci nejdou, CS jsem radši ani nezkoušel.

Můžu Vám upřímně říct, že jsem z toho paf :D Jelikož třeba Hamachi funguje na výbornou, ale nesmí mi do počítače (bastl, který není opensource).

[Petr Maleček]

Ještě mi napadlo ... nemůže být problém v tom, že nepoužívám u VPN žádnou GW ? Nechávám proudit internet přes klientovo rozhraní, protože v naší síti je NAT zakázán, takže DHCP nepřidělí adresu GW klientovi.

[archen]

Už je to sice mrtvé vlákno, ale rozchodil si to nakonec?