Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: martyd420 02. 07. 2024, 20:26:47
-
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)
[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ů"
[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
-
tcpdump port 53?
-
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í?
-
ď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.
-
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
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
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)
-
Zde ještě výpis dig +trace root.cz
Zdá se tedy problém s IPv6 ?
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
-
* zkusil jsem ipv6 úplně zakázat (vůbec nepotřebujeme), ale chová se to stejně...
-
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?
-
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.
-
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?
-
tracepath výsledek je stejný při zapnutém i vypnutém wg0
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 :D
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ě:
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ý"?