bridged OpenVPN, podle čeho se generuje MAC adresa pro tap?

[Martin Kiklhorn]

V dokumentaci OpenVPN se doporučuje v případě použití konfigurace bridge + remote DHCP server používat na straně DHCP serveru class podle MAC adresy začínající 00:FF. Ale už nikde není zmíněno že to platí pro tap rozhraní pouze na MS Windows.

Na základě čeho se generuje v Linuxu/*Buntu MAC adresa která bude přiřazena tapu? Vypadá to že je generuje náhodně.

Kód: [Vybrat]

cat /var/lib/dhcp/dhcpd.leases | grep -B1 lucipad
  hardware ethernet 9a:70:35:96:f7:79;
  client-hostname "lucipad";
--
  hardware ethernet 76:23:3a:54:b9:83;
  client-hostname "lucipad";
--
  hardware ethernet 7a:d2:ad:e8:18:1f;
  client-hostname "lucipad";
--
  hardware ethernet da:eb:24:b2:c7:9c;
  client-hostname "lucipad";
--
  hardware ethernet 92:17:30:5b:c6:fe;
  client-hostname "lucipad";
--
  hardware ethernet e2:69:7b:60:ec:38;
  client-hostname "lucipad";
--
  hardware ethernet 62:3c:a7:7c:bc:b0;
  client-hostname "lucipad";
--
  hardware ethernet da:ff:92:dd:51:36;
  client-hostname "lucipad";
--
  hardware ethernet 7a:28:b1:a7:9f:e6;
  client-hostname "lucipad";
--
  hardware ethernet 66:9f:03:7a:72:dd;
  client-hostname "lucipad";
--
  hardware ethernet e6:b7:7d:f2:c6:a8;
  client-hostname "lucipad";
--
  hardware ethernet 02:ee:27:74:2c:0e;
  client-hostname "lucipad";
--
  hardware ethernet 5e:da:65:ff:c4:a0;
  client-hostname "lucipad";
--
  hardware ethernet 8e:25:60:62:51:9f;
  client-hostname "lucipad";
--
  hardware ethernet be:eb:9e:f9:1a:8c;
  client-hostname "lucipad";
--
  hardware ethernet be:eb:9e:f9:1a:8c;
  client-hostname "lucipad";
--
  hardware ethernet be:eb:9e:f9:1a:8c;
  client-hostname "lucipad";Jediné co mají společné je nastavený bit "locally administered address" a v tom pro mne vidím dvě chybičky
1) nevím jak jej využít v DHCPd od ISC
2) mívají jej také nastavené virtuální mašiny připojené do ehernetových portů které jsou součástí virtuálního bridge stejně jako tap0 na straně DHCP serveru. Takže tudy asi cesta stejně nepovede.

Hostname strojů předem neznám, sniffnul jsem si komunikaci a žádný vendor string také neposílá.

[Martin Kiklhorn]

Vyselo mi to tu rozepsané od včera, odeslal jsem, protože se třeba bude hodit někomu alespoň částečné řešení.
ve faq, druhá metoda je doporučeno použití na straně serveru server-bridge bez parametrů.
Server pak opravdu posílá

Kód: [Vybrat]

PUSH_REPLY,route-gateway dhcpPřibyl mi totiž další problém - na straně linuxového klienta rozhraní tap po navázání spojení skončilo down, musel jsem ručně spouštět dhclient, pak si údaje z dhcp serveru načetl. Na serveru je tap0 v bridgi s forward delay na 0, takže tady to blokovat nebude. Jestli se mi to kouše s knetworkmanagerm jsem nezkoumal.
Vyzkoušel jsem i klienta na Windows a dostával jsem

Kód: [Vybrat]

OpenVPN ROUTE: failed to parse/resolve default gateway: dhcp
Tak jsem to překopal, nastavení dhcp do lokální sítě přiděluje dhcp server, pro vpn klienty OpenVPN server, jen jsem rozdělil rozsah na dvě navazující části.

Takže částečné řešení bridgované openvpn -

Na straně serveru

Kód: [Vybrat]

mode server
tls-server
dev tap0
port 1194
proto udp
#server-bridge
server-bridge 192.168.111.1 255.255.255.0 192.168.111.150 192.168.111.249
duplicate-cn
push "route-gateway 192.168.111.1"
push "route 192.168.111.0 255.255.255.0"
push "route 192.168.168.0 255.255.255.0"
client-to-client
keepalive 10 120
ca privnet/ca.crt
cert rn.cz.crt
key rn.cz.key
dh dh1024.pem
tls-auth ta.key 0
comp-lzo
log /var/log/vpn.log
user nobody
group nobody
persist-key
persist-tun
verb 3
status openvpn-status.log
multihome
dhcp server

Kód: [Vybrat]

#dratova sit (resp.br0)
#pokracovani .150-249 prideluje openvpn
subnet 192.168.111.0 netmask 255.255.255.0 {
  range 192.168.111.20 192.168.111.149;
  option domain-name-servers 192.168.111.1;
  option routers 192.168.111.1;
  option broadcast-address 192.168.111.255;
  default-lease-time 60000;
  max-lease-time 120000;
}

Na straně serveru mám zařízeno v síťovém skriptu /etc/conf.d/net přihazování tap0 pokud se v systému objeví, do br0, ale to je gentoo

Na Ubuntu bych to dělal přes up skript (up "/etc/openvpn/up.sh br0")
více zde - https://help.ubuntu.com/community/OpenVPN

klienti

Kód: [Vybrat]

client
dev tap
proto udp
remote muj.server.cz 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert klient1.crt
key klient1.key
tls-auth ta.key 1
comp-lzo
verb 3

Navázané spojení vydrží cca 8,5 hod. Je to polovina času lesingu dhcp, jakmile si sahne pro obnovení tak dostane nastavení již od skutečného DHCP serveru včetně default GW. Takže pokud není pro klienta (identifikovat jej lze pouze podle hostname, viz minulý post) rezervován záznam s nastavením i na dhcp serveru tak se přenastaví i default routa a všechno je špatně.

jiná IP klienta vpn serveru vadit nemusí - direktivy multi a float, ale jsem opět u první otázky - jak na dhcp serveru jednoznačně identifikovat že "pochází" z VPN bez znalosti hostname, případně jak zařídit aby adresy přiděloval vpn server i při jejich obnově?

[honzik666]

aktualne resim stejny problem. Procetl jsem, co se dalo. Filtrovani/trideni dhcp pozadavku na strane DHCP server na zaklade MAC adresy tap zarizeni klient mi prijde naivni reseni. Jak a proc vubec mam uzivatelum site zaridit, ze si to nastavi zrovna takhle? Produkcni reseni, ktere by si mi libilo, je prinutit vpn server, aby umel obarvit dhcp requesty od klientu napr. nazvem VPN site, pripadne a jeste lepe pomoci DN z klientskeho X509 certifikatu. Pod barvenim bych si dokazal predstavit nejakou 'custom' dhcp-option.

Jinak ja jsem v situaci, ze to po me jeden zakaznik v podstate chce a tudiz budu muset prijit s nejakym fcnim resenim. Pokud by se naslo nejake existujici reseni, urcite by me zajimalo.

Honza