Konfigurationsfilens namn kritiskt på Wireguard linuxklient

Vår huvudtjänst.
Post Reply
gostal
Posts: 16
Joined: Sun 24 May 2020, 09:55

Konfigurationsfilens namn kritiskt på Wireguard linuxklient

Post by gostal »

Det märks att wireguard är ett arbete under utveckling för det finns en del råa kanter.
Kör Linux Mint 19.1, installerade Ubuntu-repot, wireguard och resolvconf. Laddade sedan ned en
konfigurationsfil och sparade den som wireguard-latitude-e6520.conf under /etc/wireguard.
Provade

Code: Select all

sudo wg-quicksudo wg-quick up wireguard-latitude-e6520
varpå systemet svararade: No such file, eller något i sammanhanget liknande nonsens.

Kopierade då konfigurationsfilen till win10 och där var det inga problem att få igång
wireguard och kollen på https://ipcheck.5july.net/ gav tumme upp. Tänkte då att kanske
är det något med sökvägen på linux men trodde inte mycket på det ocn man wg-quick
bekräftade att /etc/wireguard ska sökas igenom. Provade ändå att explicit peka ut filen:

Code: Select all

sudo wg-quick up /etc/wireguard/wireguard-latitude-e6520.conf
wg-quick: The config file must be a valid interface name, followed by .conf 
Åntligen ett meningsfullt felmeddelande!! Något fel på filnamnet alltså men vilka
är reglerna för hur det ska se ut? Har inte lyckats hitta den informationen så provade
namnet wg0.conf som jag sett på några sidor och då fungerade det.

Code: Select all

sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.27.194/24 dev wg0
[#] ip -6 address add fdab:1337:1337:27::194/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
och

Code: Select all

ifconfig
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.125  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::4cb:3e97:5c73:ebbd  prefixlen 64  scopeid 0x20<link>
        ether d4:be:d9:19:f1:11  txqueuelen 1000  (Ethernet)
        RX packets 215112540  bytes 90196898617 (90.1 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 487653016  bytes 348770054948 (348.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xe2d00000-e2d20000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1112817  bytes 100606528 (100.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1112817  bytes 100606528 (100.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 10.0.27.194  netmask 255.255.255.0  destination 10.0.27.194
        inet6 fdab:1337:1337:27::194  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 1765  bytes 1122048 (1.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1735  bytes 338268 (338.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
och

Code: Select all

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eno1
10.0.27.0       0.0.0.0         255.255.255.0   U         0 0          0 wg0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eno1
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eno1
Ser ut som att det fungerar och både IP4 och IP6 adresser är satta på wg0.

Kollade då på https://ipcheck.5july.net/ men där blev det tumme ned!!

Kopplade ned, ändrade namnet till integrity_vpn.conf som det står i guiden och
då blev det tumme upp på https://ipcheck.5july.net/!!

Provade sedan med namnet gostal_vpn.conf och det kopplar upp men som jag misstänkte
efter det delvisa misslyckandet med wg0.conf så blev det tumme ned på
https://ipcheck.5july.net/.

Det verkar som att kollskriptet på https://ipcheck.5july.net/ förutsätter att
namnet på konfigurationsfilen är integrity_vpn.conf. Här tycker jag det kunde
vara bättre så att namn som wireguard accepterar även accepteras av
https://ipcheck.5july.net/. Tycker även att det borde stå att man inte kan
spara konfigurationsfilen med vilket namn som helst och gärna en fingervisning
om vilka namn som är OK.

Men varför fungerade det på windows med ett annat namn?

Efter att ha grävt runt på https://www.wireguard.com/ ett tag så framkom det
att windowsklienten är instoppad i eller samarbetar med wintun som tydligen inte
har något problem med vilket namn konfigurationsfilen har. Min gissning är att
windowsklienten översätter namnet till något gångbart baserat på innehållet i
konfigurationsfilen och att uppkopplingen i detta fall får namnet integrity_vpn
och då blir det tumme upp. Rätta mig om jag har fel.

Man blir lite häpen över att användarvänligheten i windows är bättre än i linux
då wireguard är utvecklat för linux och rimligen borde ligga i framkant där. Det
gör det även i viss mån då senaste linuxkärnan nu fått wireguard inbyggd istället
för att köras som modul men windowsanvändarna har ju tur i att det finns
färdiga och användarvänliga skal med indikatorer i systembrickan att lägga
wireguard i. På linux får vi väl vänta på att desktopdistributionerna hunnit anpassa
nätverksgränssnitten till den senaste linuxkärnan.

/gostal
Post Reply