Velmi pomalé DNS po aktivaci WireGuardu

[martyd420]

Ahoj,
používám pro svou "vpn" wireguard. Mám jeden "server" (VPS s veřejnou IP, Debian), jeden pracovní PC (Kubuntu) a jeden komp v kuchyni (Ubuntu Server), který je z VPS používán jako backend pro ComfyUI (pro Krita plugin stable diffusion). Chci na VPS dát ještě reverzní proxy (nginx), takže na doméně abcd.xx nastavím do A veřejnou ip VPS, ale tam se jen pořeší lets encrypt a reálně ten request odbaví právě ten komp v kuchyni. (stable diffusion a storage, soukromá zálažitost pro pár kolegů. Nechi to používat ke skrytí za IP VPS, takže mám v nastavení routes zaškrknuto "use only for resources on this connection.", nicméně i bez toho zaškrknutí to v tomto směru fungovalo očekávaným způsobem)
Testuju si to pár dnů a víceméně to funguje, ale... 
Po restartu PC funguje DNS rychle. ping root.cz funguje ihned bez prodlevy. Jakmile ale naběhne wireguard, dochází k prodlevě překladu domény (4-8 sec).
Když udělám wg-quick down wg0, zase to běží rychle. Po wg-quick up wg0 se to zase zpomalí.

Do /etc/resolv.conf se mi přidává 127.0.0.53 a jinak tam mám 8.8.8.8 a 1.1.1.1
Když zkusím dig @127.0.0.53 example.com - jede to rychle se zapnutým i vypnutým wg0. Zakomentování a flush resolvctl nic nezmění. V iptables nic k portu 53 není.

Čím to může být? Jak hledat příčinu? Našel jsem pár podobných problémů, ale nepomohlo mi to.
DNS je opravdu velmi pomalé, je to hodně znát i v prohlížeči, protože ta prodleva je na každém překladu domény i když se mnohokrát za sebou dotazuju na stejnou doménu.
Zpomalení se projevuje na kompu v kuchyni i na PC, na VPS ne. Projevuje se i v případě, že jsem nastavil síť manuálně s dns 8.8.8.8
Díky, níže konfigurace wireguardu

Konfigurace "serveru" (VPS)

Kód: [Vybrat]

[Interface]
Address = 10.8.66.1/24
DNS = 8.8.8.8, 1.1.1.1
ListenPort = 49811
PrivateKey = ************

[Peer]
# client public key
PublicKey = ************
AllowedIPs = 10.8.66.2/32

[Peer]
PublicKey = ************
AllowedIPs = 10.8.66.3/32

[Peer]
PublicKey = ************
AllowedIPs = 10.8.66.4/32

[Peer]
PublicKey = ************   
AllowedIPs = 10.8.66.5/32

[Peer]
PublicKey = ************   
AllowedIPs = 10.8.66.6/32

Konfigurace "klientů"

Kód: [Vybrat]

[Interface]
Address = 10.8.66.xxx/32
DNS = 8.8.8.8, 1.1.1.1
PostUp = wg set %i private-key /home/....../private.key

[Peer]
PublicKey = *****
Endpoint = vpn.********.cz:49811
AllowedIPs = 10.8.66.0/24
PersistentKeepalive = 25


[Reklama]

[czechsys]

tcpdump port 53?

[Bugsa]

Je nutné tam to DNS nastavovat? Já ho tam nastavuji pouze v případě, že se má používat nějaké které mi zpřístupní ten tunel.
Když zkusíš 9.9.9.9 nebo 1.1.1.1 tak k prodlevám také dochází?

[pepa novak]

ďakkujem aj ja za radu, keď som to DNS vyhodil, všetko funguje podľa očakávania

mal som väčší problém, že mi nefungovalo RDP na Win Server cez wireguard na edgerouter x. riešením bolo nakoniec zakázať na klientoch UDP pre RDP v registroch.

[martyd420]

Zkusil jsem to DNS dát pryč a už jsem se skoro radoval, že to pomohlo...  ale zafungovalo to (zřejmě jen náhodou) jen na pracovním PC, na tom kompu v kuchyni ne. 
Když zkouším ten tcpdump, vidím rozdíl mezi ping a nslookup - ping má dlouhé prodlevy, nslookup vrací data ihned. Chová se to tak (stejně jako na PC) i se statickou konfigurací sítě..
Výpisy tcpdump: //moc mi to neříká... 

#### PING ROOT.CZ

Kód: [Vybrat]

root@s7:~# tcpdump port 53   
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp27s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:58:49.249788 IP 192.168.127.103.53792 > dns.google.domain: 20057+ A? root.cz. (25)
07:58:49.249798 IP 192.168.127.103.53792 > dns.google.domain: 15433+ AAAA? root.cz. (25)
07:58:49.258749 IP dns.google.domain > 192.168.127.103.53792: 15433 1/0/0 AAAA 2001:67c:68::76 (53)
07:58:49.309439 IP 192.168.127.103.49249 > dns.google.domain: 11844+ PTR? 8.8.8.8.in-addr.arpa. (38)
07:58:49.318326 IP dns.google.domain > 192.168.127.103.49249: 11844 1/0/0 PTR dns.google. (62)
07:58:49.318605 IP 192.168.127.103.43651 > dns.google.domain: 60060+ PTR? 103.127.168.192.in-addr.arpa. (46)
07:58:49.327876 IP dns.google.domain > 192.168.127.103.43651: 60060 NXDomain 0/0/0 (46)
# TADY JE DLOUHÁ PAUZA
07:58:54.254412 IP 192.168.127.103.53792 > dns.google.domain: 20057+ A? root.cz. (25)
07:58:54.263676 IP dns.google.domain > 192.168.127.103.53792: 20057 1/0/0 A 91.213.160.188 (41)
07:58:54.263835 IP 192.168.127.103.53792 > dns.google.domain: 15433+ AAAA? root.cz. (25)
07:58:54.272094 IP dns.google.domain > 192.168.127.103.53792: 15433 1/0/0 AAAA 2001:67c:68::76 (53)
07:58:54.284738 IP 192.168.127.103.43848 > dns.google.domain: 31781+ PTR? 188.160.213.91.in-addr.arpa. (45)
07:58:54.301472 IP dns.google.domain > 192.168.127.103.43848: 31781 NXDomain 0/1/0 (103)

#### NSLOOKUP ROOT.CZ

Kód: [Vybrat]

root@s7:~# tcpdump port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp27s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:59:37.739640 IP 192.168.127.103.47259 > dns.google.domain: 27986+ A? root.cz. (25)
07:59:37.745437 IP 192.168.127.103.36355 > dns.google.domain: 51213+ PTR? 8.8.8.8.in-addr.arpa. (38)
07:59:37.754878 IP dns.google.domain > 192.168.127.103.36355: 51213 1/0/0 PTR dns.google. (62)
07:59:37.755198 IP 192.168.127.103.46176 > dns.google.domain: 60239+ PTR? 103.127.168.192.in-addr.arpa. (46)
07:59:37.756045 IP dns.google.domain > 192.168.127.103.47259: 27986 1/0/0 A 91.213.160.188 (41)
07:59:37.756440 IP 192.168.127.103.50893 > dns.google.domain: 26951+ AAAA? root.cz. (25)
07:59:37.772914 IP dns.google.domain > 192.168.127.103.46176: 60239 NXDomain 0/0/0 (46)
07:59:37.772919 IP dns.google.domain > 192.168.127.103.50893: 26951 1/0/0 AAAA 2001:67c:68::76 (53)


[Reklama]

[martyd420]

Zde ještě výpis dig +trace root.cz
Zdá se tedy problém s IPv6 ? 

Kód: [Vybrat]

root@s7:~# dig +trace root.cz

; <<>> DiG 9.18.24-1-Debian <<>> +trace root.cz
;; global options: +cmd
.                       87203   IN      NS      a.root-servers.net.
.                       87203   IN      NS      k.root-servers.net.
.                       87203   IN      NS      f.root-servers.net.
.                       87203   IN      NS      i.root-servers.net.
.                       87203   IN      NS      b.root-servers.net.
.                       87203   IN      NS      e.root-servers.net.
.                       87203   IN      NS      j.root-servers.net.
.                       87203   IN      NS      l.root-servers.net.
.                       87203   IN      NS      h.root-servers.net.
.                       87203   IN      NS      c.root-servers.net.
.                       87203   IN      NS      d.root-servers.net.
.                       87203   IN      NS      g.root-servers.net.
.                       87203   IN      NS      m.root-servers.net.
.                       87203   IN      RRSIG   NS 8 0 518400 20240717170000 20240704160000 20038 . tFHN60wbjhtI2U+Ix4cThm3qQ0HMM6bbeIFvG+p1vi3y1oZcF5D0y2Jw yIXZclbP8S6bk44DxVVgdQXJl6RD3NAf6dQ3SlkUg0OHoXEJl2jIb7ax 0J+nvBxHlxwWXJrDSgUYzBhQaE6D6v3Bzpz/vsK2sZ/y4XyJWJ3uAwSd ETJixN/JWmQFla5VzWNcDxhXbSazyFbHEk+C2R12Tp7XHQt5/qjJHDMl xtu3oL2Tlrda/sTym6OpYUDroU4cbGE9feDtWUPgx/wvqhXSE6vXx0gL vFvDV05C0OlZgPE2xrx5x7piZ28VD/U871Li/G24ddPcabPiSOZsgeHK +U5txQ==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 20 ms

#######  TADY JE DLOUHÁ PAUZA  ####################

cz.                     172800  IN      NS      c.ns.nic.cz.
cz.                     172800  IN      NS      d.ns.nic.cz.
cz.                     172800  IN      NS      a.ns.nic.cz.
cz.                     172800  IN      NS      b.ns.nic.cz.
cz.                     86400   IN      DS      20237 13 2 CFF0F3ECDBC529C1F0031BA1840BFB835853B9209ED1E508FFF48451 D7B778E2
cz.                     86400   IN      RRSIG   DS 8 1 86400 20240717170000 20240704160000 20038 . GJzbcMzzjLEoxCTxp+vBi97T05K861IZykHFT2k1f88OVGD9YR0fP73D 8X6Nk7mzoHfnMzOrEq0ZB+pOo7IIdtke5Day2fDMGUYM/hdoZXR7GAgI TerookLcVBYTAbnykxQzknxyTF8hDmMTrtkNMPalyLsoz7LyITnaBr9x e1kgfW14W4uFziVUKN8Ve7mj5EI5LEp+PGN09Ctc5We+s8A6mz5Btf/5 cK2vcmenvWyo/qiMuGofSAkfXuQF3nqSCnfij5/Fu8iZZi6FWLSHOOnB soLxWaxRrQDqEe6yWjSQfXhSXSbrrBO4KoT5Af/10c/5GXH3822Smtsh FTnkSg==
;; Received 620 bytes from 202.12.27.33#53(m.root-servers.net) in 28 ms

;; UDP setup with 2001:678:1::1#53(2001:678:1::1) for root.cz failed: network unreachable.
;; no servers could be reached

;; UDP setup with 2001:678:1::1#53(2001:678:1::1) for root.cz failed: network unreachable.
;; no servers could be reached

;; UDP setup with 2001:678:1::1#53(2001:678:1::1) for root.cz failed: network unreachable.
root.cz.                3600    IN      NS      ns.iinfo.cz.
root.cz.                3600    IN      NS      ns6.adminit.cz.
root.cz.                3600    IN      DS      906 13 2 400C3DF1163715A2251C21E5E19195990E6B639D894BDE240D2D9AC4 A1C8153F
root.cz.                3600    IN      RRSIG   DS 13 2 3600 20240718062134 20240704045134 61498 cz. EHwfCHoMhbB1BGL6mra/fQl2utGkMdY5S3QRdYBSEEXG/WTvXu8CTkGg JC3V6gdrPTk5Bi33iB4J/YEbgNmDYA==
;; Received 319 bytes from 194.0.12.1#53(a.ns.nic.cz) in 12 ms

root.cz.                600     IN      A       91.213.160.188
root.cz.                600     IN      RRSIG   A 13 2 600 20240722141153 20240622134341 906 root.cz. HZFr68c2Dp48NQAxSIMwrNTz/zk5GP2MS9oNO7U557sqAWcK7DDUywil QfYSJAeereE+X+P/veg7nswXeOGsoA==
root.cz.                600     IN      NS      ns6.adminit.cz.
root.cz.                600     IN      NS      ns.iinfo.cz.
root.cz.                600     IN      RRSIG   NS 13 2 600 20240722141153 20240622134341 906 root.cz. QfcUopIdwrmRoxL9xwk49cj3sC/oajsoQgF4ekAq/aXcYBb10Ztu0azJ l1ZSh70wKmyJDY8/sogwpDFowFPrCg==
;; Received 339 bytes from 91.213.160.5#53(ns.iinfo.cz) in 8 ms



[martyd420]

* zkusil jsem ipv6 úplně zakázat (vůbec nepotřebujeme), ale chová se to stejně...

[ja.]

Ja by som tipoval rozbite nastavenie DNS, pretoze sa vrta do /etc/resolv.conf ked tam je na to demon. Moj tip: Bude tan DNS na interfaci, ktory po zapnuti tunela nevie odoslat uz nic a caka na timeout, kym sa vyskusa iny resolver cez iny interface.

`resolvectl status` pred a po zapnuti wg tunela co povie?

[farbydos2]

Zkusil bych ještě tipy z: https://wiki.archlinux.org/title/WireGuard#Troubleshooting. Teoreticky může např. NM interagovat s wg... Zkusil bych

• nastavit, aby se o wg tunel nestarala žádná další služba.
• potvrdit, že na wg rozhraní neodchází DNS dotazy, když se pouští dig. Podle nastavení by se přes wg tunel neměly klást DNS dotazy: AllowedIPs neobsahuje adresy DNS serverů, pokud se nepletu. Pokud nechcete laborovat s tcpdump, můžete zkusit trochu přívětivější wireshark. Cílem je sledovat rozhraní wg, ne přímo ethernet/wifi. Obecně mi přijde lepší nechávat konfiguraci DNS ve wg, pokud je cílem přidat DNS server dosažitelný přes wg.
• nechat wg tunel bez konfigurace DNS a postupně DNS servery přidat jiným způsobem. Ideálně s vypnutým i zapnutým wg, což ověří, že jsou z lokální sítě dosažitelné
• tip, který nesouvisí s DNS: je docela možné, že u wg bude potřeba upravit MTU, podle konektivity. Pokud se používá nějaké tunelování PPPoE, tunelování kvůli IPv6 atp., může to mít vliv i na provoz, který nejde přes wg.

[Jose D]

zabýval jsem se nedávno zajímavým MTU problémem způsobeným tunelováním, nemůže být příčina tady?

když dáš

tracepath IP.Tveho.DNS.Serveru

na svůj DNS server, tak to projde bez snížení MTU?

[martyd420]

tracepath výsledek je stejný při zapnutém i vypnutém wg0

Kód: [Vybrat]

root@s7:~# tracepath 8.8.8.8
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.127.1                                         0.535ms
 1:  192.168.127.1                                         0.389ms
 2:  192.168.99.20                                         0.793ms
 3:  192.168.100.1                                         2.672ms
 4:  10.23.0.1                                            13.408ms
 5:  10.11.34.161                                          3.607ms
 6:  xxxxxxxx.poda.cz                             9.170ms asymm  7
 7:  xxxxxxxx.poda.cz                            10.479ms
 8:  72.14.243.146                                        16.257ms
 9-30:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

Roztomilé je, že po odstranění DNS z konfigurace wireguard mi desktop (Kubuntu 22.04) běží bez problému, ale ten komp v kuchyni (Debian 12 bez gui) má teď prodlevy při zapnutém i vypnutém wg0
NetworkManager tam není, "resolvectl: command not found". Je to default instalace debianu bez jakýchkoli úprav, experimentuju teď až s tím DNS.  Síť je nastavena staticky ručně:

Kód: [Vybrat]

auto enp27s0
iface enp27s0 inet static
        address 192.168.127.103
        netmask 255.255.255.0
        gateway 192.168.127.1
        dns-nameservers 8.8.8.8 1.1.1.1


Pokud by něco používalo DNS z DHCP, tak dig @192.168.127.1 root.cz funguje ve všech případech rychle.

Btw do toho resolv.conf jsem ručně nehrabal ani na desktopu, zkoušel jsem jen zakomentovat to 127.0.0.53, ale to až po tom, co se to rozsypalo. Takže wg0 nemá nastavené DNS, používaná síťovka má ručně nastavené 8.8.8.8 a 1.1.1.1. Jde nějak linuxu říct: "používej vždy tento konkrétní DNS server a nikdy ne jiný"?