Dotaz: WireGuard do bridge

[Honza]

Dobrý den. Rád bych propojil dvě lokality mezi sebou pomocí Wireguardu tak, aby v každé lokalitě byla dostupná sít 10.50.10.0/24. Je to řešitelné ? Je možné dát Wiregurd interface do bridge ? V síti 10.50.10.0/24 zároveň běží DHCP server, který by měl být dostupný na obou dvou místech. Díky.

---

---

Odpovědi

[billgates]

Nie, wireguard je tunel na tretej (IP) vrstve.

[xxl]

Přímo WireGuardem to nejde. Ale můžeš zkusit přes L3 (WireGuard) protunelovat L2 (gretap).

https://notes.superlogical.ch/pages/note_wg/nolayer2/

[mmcze]

Sám na tohle používám GRE tunel.

Nějaké studium konfigurace asi nebude nutné, když ti řeknu, co přesně spouštím na obou stranách:

Strana1: VPN IP: 10.200.0.110, LAN IP 192.168.0.231, přístup do LAN jen pomocí GRE tunelu

#!/bin/bash iptables -I INPUT -s 10.200.0.105 -p gre -j ACCEPT ip link add gretap1 type gretap local 10.200.0.110 remote 10.200.0.105 ip link set dev gretap1 up brctl addbr br0 brctl addif br0 gretap1 ip addr add 192.168.0.231/24 dev br0 ip link set br0 up

Strana 2: VPN IP: 10.200.0.105, LAN IP 192.168.0.230, přístup do LAN pomocí eth1

#!/bin/bash sleep 20 iptables -I INPUT -s 10.200.0.110 -p gre -j ACCEPT ip link add gretap1 type gretap local 10.200.0.105 remote 10.200.0.110 ip link set dev gretap1 up brctl addbr br0 brctl addif br0 gretap1 brctl addif br0 eth1 ip addr add 192.168.0.230/24 dev br0 ip link set br0 up

[mmcze]

Sorry, blbé formátování a nejsem přihlášen, abych mohl editovat, tak znovu.

Sám na tohle používám GRE tunel.

Nějaké studium konfigurace asi nebude nutné, když ti řeknu, co přesně spouštím na obou stranách:

Strana1:
VPN IP: 10.200.0.110, LAN IP 192.168.0.231, přístup do LAN jen pomocí GRE tunelu

#!/bin/bash
iptables -I INPUT -s 10.200.0.105 -p gre -j ACCEPT
ip link add gretap1 type gretap local 10.200.0.110 remote 10.200.0.105
ip link set dev gretap1 up
brctl addbr br0
brctl addif br0 gretap1
ip addr add 192.168.0.231/24 dev br0
ip link set br0 up

Strana 2:
VPN IP: 10.200.0.105, LAN IP 192.168.0.230, přístup do LAN pomocí eth1

#!/bin/bash
sleep 20
iptables -I INPUT -s 10.200.0.110 -p gre -j ACCEPT
ip link add gretap1 type gretap local 10.200.0.105 remote 10.200.0.110
ip link set dev gretap1 up
brctl addbr br0
brctl addif br0 gretap1
brctl addif br0 eth1
ip addr add 192.168.0.230/24 dev br0
ip link set br0 up

[mmcze]

Ugh, nějak se změnilo něco v síti po cestě a mě to přestalo fungovat, zřejmě proto, proč to tobě nefungovalo od začátku(divný je, že přes půlku světa to fungovalo dál)...

Stačí na každou stranu přidat na konec jeden řádek: ifconfig br0 mtu 1280

[Max]

Lepší, než si hrát s MTU, je nastavovat MSS.
Zdar Max

[Honza]

Prosím, Maxi, mohl by jste to rozvést a uvést konkrétní příklad v rámci tohoto případu ?

[Max]

Prostě natvrdo přepisovat velikost MTU na jednotlivých interfacích je cesta do pekel. Pokud mám nějakou službu, která s tím má problém a nedokáže si to sama nějak uřídit, tak prostě v mangle si vynutíme konkrétní MSS, příklad:

# přepiš MSS na 1280 v případě, že si někdo bude přát vyšší jak 1281
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1281:1536 -j TCPMSS --set-mss 1280

Kontrola:

iptables -t mangle -vL

Chain PREROUTING (policy ACCEPT 1969K packets, 337M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 1645K packets, 188M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 323K packets, 149M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3052  162K TCPMSS     tcp  --  any    any     anywhere             anywhere             tcp flags:SYN,RST/SYN tcpmss match 1281:1536 TCPMSS set 1280

Chain OUTPUT (policy ACCEPT 1311K packets, 324M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1777K packets, 534M bytes)
 pkts bytes target     prot opt in     out     source               destination

Jinak Mikrotik na to má KB: Change_MSS. Zywall na to má zase u nastavení ipsecu klikátko atd.
Zdar Max

[xxl]

Nebo se to dá udělat nějak takhle:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

jak je uvedeno na stránce odkazované v tomto příspěvku.

[j]

Az se doucis ty uplne nejzakladnejsi zaklady sitovani, tak ti treba i dojde, ze propojovat naprosto cokoli na L2 je nejblbejsi ze vsech blbych napadu.

---

Dete s tim guuglem dopice!

[billgates]

Niekedy to ma zmysel. Napriklad ak ma firma v budove viac poschodi a chcu mat rovnake subnety na roznych poschodiach, ale zaroven nechcu vystavit siet moznemu utoku, kedze kabel medzi poschodiami opusta ich priestory a je vedena v spolocnej kablovej sachte, kam maju pristup aj cudzi ludia. Vtedy sa oplati aj L2 tunelovat cez nieco sifrovane.

[mmcze]

Ten nejblbější z blbých nápadů, mi takhle funguje už druhým rokem, bez jakéhokoli mého dalšího zásahu.

Díky GRE, mohu mít kontejner na druhé straně světa kde běží DLNA server, jednoduše připojený do sítě doma a všechny televize, se k tomuto DLNA serveru mohou bez problémů připojit.

Pokud to funguje, nemusím se o to starat a vyřešilo to mou potřebu, nemám s tím nejmenší problém.

Proč je to dle tebe blbý nápad?

A máš ten tunel z druhého konce světa šifrovaný?

[mmcze]

Když to běží přes Wireguard, tak asi jo.

Ale jsi v té tvé konfiguraci dokonale utajil.

[Josef Kufner]

Myslím, že to dobře vyplynulo z kontextu

Ta naznačená konfigurace by fungovala i bez WireGuardu. Akorát by to nebylo šifrované.

A jak vidíš, tazatel to ještě tak docela nezprovoznil, ačkoliv se všechny ty informace dají dohledat i gůglem nebo načist v manuálech.

Takže by se bývalo nic nestalo, kdyby v naznačené konfiguraci zmínka o wireguardu byla. Zvlášť, když ten Wireguard snižuje MTU na svých rozhraních na 1420 .

[mask]

Zbytecna ztrata casu.

Podivej se na:

tailscale zerotier cloudflare access

Zprovozneni behem par minut. Bez nutnosti public IPv4. Nulove nebo minimalni naklady. Nezavislot na lokaci Snadno skalovatelne.

[Honza]

Tak je to nějaký divný. Povedlo se mi to rozchodit. Obě strany mezi s sebou pingnu. DHCP mi také chodí na obou dvouch stranách. Ale jakmile se chci z jedné strany na druhou navázat SSH spojení, nebo HTTPS spojení, tak nic. Prostě nedostupné. Myšleno spojení po vnitřní síti. Tedy např. https://10.50.10.101 Ping ale prochází, DHCP broadcast taky, IP dostanu, ale tohle neběhá.

Byla by nějaká myšlenka, na co se zaměřit ?

[vencour]

Nemusí se nastavit proxy arp?
Co pustit tcpdump na zdroji a cíli a zjistit, co tam vlastně a jak komunikuje?

[Honza]

Proč SSH projde, ale cokoli dalšího "většího" NE ?

To je záhada, na kterou ti nikdo neodpoví, protože nikdo nemá křišťálovou kouli, aby věděl, jak to máš nakonfigurované.

[bigBRAMBOR]

vzdyt pises nahore ze ti ssh neprojde, tak ted fakt nevim

[vencour]

Tak koukni, co kam přesně a s jakýma zdrojovýma adresama prochází. Nejde něco směrem tam tunelem a zpět "normální linkou" třeba?
Jsou komunikující IP adresy opravdu takové, jak píšeš?

[Dušan]

Žeby MTU?

[mmcze]

Jak pociťuješ, že se ti děje "něco divného" se sítí co na první pohled nechápeš, je na 90% na vině MTU.

[Honza]

No jo, ale co a kde ? Viz. nize.

[Honza]

Na MTU už jsem také myslel.
Bohužel, tento portál mi při kopírování z konzole hlásí, že "Značka LOOPBACK,UP,LOWER_UP není povolena!" a já neumím to obejít.
Zasílám tedy přes pastebin.

MTU na serveru
https://pastebin.com/W01s3x3F

MTU na klientovi
https://pastebin.com/m8ZmMbft

Ping ze serveru na klienta, který je za GRE tunelem projde pouze do velikosti 1354

>>> ping 192.168.1.91 -s 1354 -c 3
PING 192.168.1.91 (192.168.1.91) 1354(1382) bytes of data.
1362 bytes from 192.168.1.91: icmp_seq=1 ttl=64 time=5.40 ms
1362 bytes from 192.168.1.91: icmp_seq=2 ttl=64 time=5.55 ms
1362 bytes from 192.168.1.91: icmp_seq=3 ttl=64 time=5.30 ms

--- 192.168.1.91 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 5.298/5.418/5.554/0.105 ms

Ping ze serveru na klienta, který je za GRE tunelem o velikosti větší než 1354 už neprojde

>>> ping 192.168.1.91 -s 1355 -c 3
PING 192.168.1.91 (192.168.1.91) 1355(1383) bytes of data.
From 192.168.1.102 icmp_seq=1 Frag needed and DF set (mtu = 1396)
From 192.168.1.102 icmp_seq=2 Frag needed and DF set (mtu = 1396)
From 192.168.1.102 icmp_seq=3 Frag needed and DF set (mtu = 1396)

--- 192.168.1.91 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 17ms

Poradil by někdo, jak správně (a kde všude) nastavit MTU, pakliže je to tento problém ?
Tady mé znalosti končí.

Děkuji.

[vencour]

Ok, nápověda ...

$ ip li help
Usage: ip link add [link DEV] [ name ] NAME
		    [ txqueuelen PACKETS ]
		    [ address LLADDR ]
		    [ broadcast LLADDR ]
		    [ mtu MTU ] [index IDX ]
		    [ numtxqueues QUEUE_COUNT ]
		    [ numrxqueues QUEUE_COUNT ]
		    type TYPE [ ARGS ]

	ip link delete { DEVICE | dev DEVICE | group DEVGROUP } type TYPE [ ARGS ]

	ip link set { DEVICE | dev DEVICE | group DEVGROUP }
			[ { up | down } ]
			[ type TYPE ARGS ]
		[ arp { on | off } ]
		[ dynamic { on | off } ]
		[ multicast { on | off } ]
		[ allmulticast { on | off } ]
		[ promisc { on | off } ]
		[ trailers { on | off } ]
		[ carrier { on | off } ]
		[ txqueuelen PACKETS ]
		[ name NEWNAME ]
		[ address LLADDR ]
		[ broadcast LLADDR ]
		[ mtu MTU ]
		[ netns { PID | NAME } ]
		[ link-netns NAME | link-netnsid ID ]
		[ alias NAME ]
		[ vf NUM [ mac LLADDR ]
			 [ vlan VLANID [ qos VLAN-QOS ] [ proto VLAN-PROTO ] ]
			 [ rate TXRATE ]
			 [ max_tx_rate TXRATE ]
			 [ min_tx_rate TXRATE ]
			 [ spoofchk { on | off} ]
			 [ query_rss { on | off} ]
			 [ state { auto | enable | disable} ]
			 [ trust { on | off} ]
			 [ node_guid EUI64 ]
			 [ port_guid EUI64 ] ]
		[ { xdp | xdpgeneric | xdpdrv | xdpoffload } { off |
			  object FILE [ section NAME ] [ verbose ] |
			  pinned FILE } ]
		[ master DEVICE ][ vrf NAME ]
		[ nomaster ]
		[ addrgenmode { eui64 | none | stable_secret | random } ]
		[ protodown { on | off } ]
		[ protodown_reason PREASON { on | off } ]
		[ gso_max_size BYTES ] | [ gso_max_segs PACKETS ]

	ip link show [ DEVICE | group GROUP ] [up] [master DEV] [vrf NAME] [type TYPE]

	ip link xstats type TYPE [ ARGS ]

	ip link afstats [ dev DEVICE ]
	ip link property add dev DEVICE [ altname NAME .. ]
	ip link property del dev DEVICE [ altname NAME .. ]

	ip link help [ TYPE ]

TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |
	   bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |
	   gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |
	   vti | nlmon | team_slave | bond_slave | bridge_slave |
	   ipvlan | ipvtap | geneve | bareudp | vrf | macsec | netdevsim | rmnet |
	   xfrm }
vencour@No606haven ~ $ 

(a pro jednoduché lidi přímo znění ... #ip li set dev eth0 mtu 1000)

[Honza]

Mohu poprosit tzv. po lopate ? Jak nastavit mtu vim. Jak pres ipconfig, tak pres ip. Jen nevim (nerozumim) nad kterym interface a jestli na strane serveru nebo klienta - viz. prispevek vyse.

[Josef Kufner]

Na tom bridgi, aby se přeposílané pakety i s přidanou hlavičou vešly do Wireguardích paketů a ty se vešly do běžného MTU.

[Honza]

To znamená nastavit to na br0 jak na serveru, tak na klientovi ? Na jakou hodnotu ideálně ?

[Honza]

Ať nastavím, co nastavím, prostě mi to nechodí :(
Jestli tomu rozumím dobře, tak bych měl nastavit na zařízení br0 na obou stranách (server + klient) mtu na vyšší hodnotu, než je wireguard a gre tunel tak, aby se to do toho vše vešlo zabalit. Ale když nastavím na br0 mtu na 1500 nebo 2000, tak to stejně nechodí. Resp. rozbije se to ještě víc a ping o velikosti 1354 už taky neprojde.

[xxl]

Wireguard interfdace má MTU 1420. Takže jestli to dobře počítám, tak

velikost [payload packetu na interfacu wireguardu] - [ip header] - [ethernet header] -[gre header]

1420 - 20 - 14 - 32 = 1354

To je velikost toho tvého pingu, co ještě projde.

Takže to je max velikost MTU na tvých bridge rozhraních na obou stranách.

[Josef Kufner]

mtu na vyšší hodnotu

Naopak. Na nižší. Wireguard i ten bridge si přidá nějaké hlavičky navíc a to celé se musí vejít do MTU na fyzické síťovce, protože když pošleš moc velký paket, tak ti ucpe kabel. Pokud však na začátku nasekáš data na menší pakety (s menším MTU), tak po přidání hlaviček bridge a Wireguardu se pořád ještě ty pakety vejdou do MTU na síťovce a kabel se neucpe.

[Honza]

Ještě mě napadlo, co zvednout MTU přímo tomu Wireguardu (MTU=1500) ? To by nebylo řešení ?

ne

[billgates]

Tím pádem na to kašlu, protože tohle prostě nechodí a nahodím OpenVPN. S hodnotou MTU=1000 na bridge to sice začne fungovat trochu líp, ale pořád to nechodí tak, jak by to chodit mělo. Např. webová stránka webmailu se načte, ale nic ostatního (složitějšího) už ne - např. rozhraní VMware WebUI. Pokud např. spustím WinSCP, tak se na druhou stranu připojím, mohu procházet adresáři, ale jakmile dám cokoli kopírovat zprava do leva nebo opačně, tak to padne. Fakt už nevím. Řešení WireGuard a nad tím GRE zřejmě není cesta a bude potřeba se vrátit k ověřeným řešením (OpenVPN).

[billgates]

Spravne rozhodnutie.

[:47]

A nezahazuješ ty náhodou všechny icmp pakety kromě pingu?

[zipi]

Pokud použiješ GRE tak doporučuji všechny pakety, co vedou do GRE upravovat na MSS 1356 - pak by ti vše bude chodit jak má - několikrát jsem něco podobného řešil.

[Honza]

Prosím, šlo by to detailněji ? Příklad ? Děkuji.

[billgates]

Pozor, treba mysliet este na to, ze GRE je este vlozene do dalsieho tunelu, ktory z toho tiez oreze. V tomto pripade naozaj je najlepsie riesenie OpenVPN na L2. Navyse to po novom podporuje aj 802.1q a rovnake sifrovanie ako WireGuard (ChaCha20Poly1305). Nie je dovod robit taketo sialene somariny (WireGuard + GRE).

[Honza]

Původní myšlenka, proč WireGuard, byla kvůli daleko vyšší propustnosti, než co má OpenVPN. Pak jsme ale narazili na to, že kvůli pár věcem musíme jednu síť protáhnout po L2 a od té doby jsem řešil problém, že něco nechodilo tak, jak by mělo. Teď jsem ve stavu, kdy jsem to komplet hodil na OpenVPN a vše běží jak má. Prostě, zkusil jsem to a nefungovalo to, takže návrat k osvědčenému řešení. Obě dvě lokality máme spojené full-duplexním 200Mbps linkou. Bohužel, ztráty na propustnosti jsou znát.

[billgates]

Divne. Pouzivame takto OpenVPN hromadne (tisice nodov) a vsade sa nam to podarilo vyladit tak, aby tie straty boli prakticky nedetegovatelne. Mas vsade najnovsie OpenVPN 2.5 a nastavene ChaCha20Poly1305, pripadne AES-GCM a HW s podporou AES akceleracie?

[Honza]

Všude mám OpenVPN, která je standartně v repozitářích Debianu 10.

ii  openvpn                        2.4.7-1                      amd64        virtual private network daemon

v server.conf pak toto...

...
tls-auth /etc/openvpn/server/ta.key 0
cipher BF-CBC
comp-lzo
...

Klíč "ta.key" je generovaný standardně přes

openvpn --genkey --secret ta.key

Nějaký nápad na úpravu ? A jak případně zjistit, zda-li HW má podporu AES akcelerace ?
Zřejmě to bude chtít po letech revizi konfigurace.

[billgates]

No, najlepsie by bolo prejst na OpenVPN 2.5, ale kym to nie je v repozitari, tak aspon nejake male veci. Sifrovanie treba zmenit na AES-GCM (napriklad AES-128-GCM). Ak je pouzite AES-CBC sifrovanie, tak openvpn k tomu navyse pridava HMAC vsetkych packetov, napriklad vo forme SHA-1 alebo SHA-256. Uz si nepamatam presne, co bolo defaultne v 2.4 verzii. OpenVPN funguje v rezime najprv zasifruj, potom podpis. Cize ak sa pouziva sifrovanie bez AEAD, tak po zasifrovani to este pocita HMAC. Ak sa pouzije sifrovanie s AEAD (napriklad AES-GCM alebo ChachaPoly), tak sa dalsi HMAC uz nerobi.

Cize zacal by som parametrami:

ncp-disable
cipher AES-128-GCM
compress
passtos

Dalej comp-lzo vyhodit, to uz je deprecated.

Ak je to po tcp, tak este:

tcp-nodelay

V OpenVPN 2.5 pribudlo este par zaujimavych veci na zlepsenie vykonu.

[Honza]

To zní dobře. OpenVPN běhá po UDP. Asi si s tím večer pohraju. Předpokladám, že když přidám repo OpenVPN a udělám update/upgrade, tak že by to mělo normálně projít a jen povýšit verzi serveru. Asi mi to stojí za to to vyzkoušet. Děkuju !