Že dobrega pol leta se ukvarjam s prenovo domačega omrežja. Kot del tega projekta, sem menjal tudi primarni VPN strežnik. Vendar pa ni šlo brez težav.

Že kar nekaj časa kot primarni VPN strežnik za dostop do domačega omrežja uporabljam Wireguard. Predvsem, ker je enostaven za vzdrževanje in ima dobro podporo skupnosti.

Ko sem se odločil, da bom na novo postavil Wireguard strežnik, sem si zamislil, da bom na njem imel tri ločene VPN povezave:

Vsak od teh VPNjev je v svojem VLANu. Temu primerno so različni tudi IP naslovi.

Cilj je bil imeti tri različne vmesnike na strežniku, za vsak VPN svojega.

Sama implemetacija je bila dokaj enostavna. Strežnik sem postavil s pomočjo Proxmox VE Helper-Scripts. Nato sem na strežnik dodal tri vmesnike, v WGDashoboardu pa ustvaril tri različna VPN omrežja.

Tukaj pa so se začele težave.

Težava 1: VPN vmesniki ne delujejo

Takoj po tem, ko sem na strežnik dodal še dva dodatna omrežna vmesnika, so se začele pojavljati čudne težave. Vmesniki se niso vzpostavili, posledično je na koncu padel networking.service. To je bilo prvič, da sem dodajal več omrežnih vmesnikov, vsakega s svojim IP naslovom, na en strežnik. Zato sem bil rahlo izgubljen, nisem vedel, zakaj se to dogaja, kje je težava. V dnevniških datotekah sem videl naslednje:

Nov 26 17:28:23 wg systemd[1]: Starting networking.service - Raise network interfaces...
Nov 26 17:28:24 wg ifup[132]: RTNETLINK answers: File exists
Nov 26 17:28:24 wg ifup[87]: ifup: failed to bring up eth1
Nov 26 17:28:24 wg ifup[141]: RTNETLINK answers: File exists
Nov 26 17:28:24 wg ifup[87]: ifup: failed to bring up eth2
Nov 26 17:28:24 wg systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Nov 26 17:28:24 wg systemd[1]: networking.service: Failed with result 'exit-code'.
Nov 26 17:28:24 wg systemd[1]: Failed to start networking.service - Raise network interfaces.

Najprej sem, neuspešno, želel napako odkriti in odpraviti sam. Ko sem ugotovil, da to ne bo šlo, sem se lotil raziskovanja. Ni trajalo dolgo, da sem našel krivca za težave. V pomoč mi je bil tale odgovor na StackExchange. Ker nisem podrobno razmislil, kaj želim, sem se na hitro odločil, da pustim samo prehod od primarnega vmesnika (eth0). eth1 in eth2 sta tako nastavljena brez privzetega prehoda. Ves promet gre torej po privzeti poti default via 192.168.0.1 dev eth0 onlink. Takrat se nisem zavedal, da mi bo to povzročalo težave kasneje.

Težava 2: Deluje samo en VPN (wg-admin na eth0)

Druga težava je bila, da je delal samo en VPN - wg-admin. Ne glede na to, kaj sem spremenil, wg-proxy in wg-minecraft nista delovala. Sprva sem reševanje te težave postavil na stran. Nujno sem namreč potreboval samo wg-admin VPN, ki pa je deloval brez težav.

Nekaj časa kasneje pa sem se odločil, da odpravim težavo in usposobim še druga dva VPNja. Če nič drugega, mi bo to prav prišlo pri popisovanju omrežja v Netbox.

Rešitev: Poti po meri in označevanje prometa

Pri reševanju težave sem se najprej sem se lotil preverjanja delovanja požarnega zidu na mojem usmerjevalniku. Tukaj nisem opazil težav. Ugotovil sem tudi, da paketi uspešno pridejo do mojega usmerjevalnika in potem naprej proti Wireguard strežniku. Zato sem se lotil iskanja težav na samem Wireguard strežniku. Ker me je zanimalo, kaj se dogaja s paketi, sem pognal tcpdump -i eth1 udp in se poizkusil povezati na wg-proxy VPN preko mojega telefona. Takoj, ko sem videl izpis tcpdump, sem vedel, da nekaj ni v redu. Videl sem namreč, da paketi sicer prihajajo na vmesnik eth1, vendar pa ni nobenega prometa v nasprotno smer. To mi je bilo malo čudno, vendar sem mi je zdelo, da vem, kaj se dogaja. tcpdump -i eth0 udp je potrdil, kar sem sumil. Paketi, ki so prišli na strežnik preko vmesnika eth1 so bili poslani naprej (oziroma nazaj) proti mojemu telefonu preko vmesnika eth0. To seveda ni delovalo, ker je moj usmerjevalnik takšne pakete zavrgel.

Zdaj sem vedel, kje je težava. Ugotoviti sem moral le še, kako jo odpraviti. Najprej sem se posvetoval s Claude AI. Njegov predlog sicer ni deloval, me je pa usmeril v pravo smer. Z nekaj dodatnega branja OpenWRT foruma in Wireguard dokumentacije sem dokaj hitro našel rešitev. Specifično, uporabljam Improved rule based routing rešitev.

Kako sem odpravil težavo? Naredil sem dve usmerjevalni tabeli po meri. Eno za vmesnik eth1, drugo za eth2. Primer:

echo "201 eth1_table" >> /etc/iproute2/rt_tables
ip route add default via 192.168.1.1 dev eth1 table eth1_table
ip route add 192.168.1.0/24 via 192.168.1.1 dev eth1 table eth1_table

Nato sem dodal še pravilo za usmerjanje prometa glede na oznako:

ip rule add fwmark 1 lookup eth1_table

Na koncu pa sem nastavil Wireguard vmesnik wg-proxy, da označuje ves izhodni promet z oznako 1:

wg set wg-proxy fwmark 1

Enako sem potem naredil še za vmesnik wg-minecraft. Tam sem uporabil oznako 2.

Delovanje sem nato testiral, in vse je delovalo tako, kot mora. Ostale so še neke malenkosti, ampak najbolj pomembno je, da vsi trije VPNji sedaj delujejo.