Podle mě to je srozumitelné (pro mě až teď, když jsem sti to přečetl xkrát), že prostě WG nebude terminován na (každém)koncovém zařízení, které chce používat. Takže na (nejspíš prvním) routeru právě bude jeden wiregurd démon. Otázka je, jestli to chce nějak granulárněji řešit (vyčlenit dle source, destination), ale vzhledem k uvádění 0.0.0.0 asi veškerý cíle, takže zbývá pro která zařízení chce tunelizaci aplikovat, a možností se nabízí víc, podle source IP (policy routing-ip rule from) nebo podle vstupního rozraní ( ip-rule iif) nebo podle vlan.
Abych přihodil jednu zvlášnost, (která nezpůsobuje žádné problémy), v některých situacích dostávám ICMP new gateway redirect.... No v některých... asi při každé nové srcIP dstIP komunikaci
Nastane až v situaci, kdy do hry vstoupí
smartphone s android wg klientem a zapnu na něm šoupátkem danou VPN (zbývající 2 nody mají permanentní tunel,
NATEDrouter za NATEM keepalivující na
VPS)
,
tedy režim komunikace začne z síťařského hlediska být zajímavý (z nudného point to point tunelu o dvou peerech se prostřední node(VPS) se stane multipoint node )
příklad :curl 10.5.0.NATEDROUTER
na wg rozhraní natovaného routeru se mi objeví:
istening on wg_rou-vps, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
IP 10.5.0.VPS > 10.5.0.NATEDROUTER: ICMP redirect 10.5.0.PHONE to host 10.5.0.PHONE, length 68
tentýž ICMP paket z pohledu PHONU vypadá:
interface tun0
IP 10.5.0.VPS > 10.5.0.PHONE: ICMP redirect 10.5.0.NATEDROUTER to host 10.5.0.NATED ROUTER, length 68 (snapshot paketu: PHONE->NATEDROUTER)
ale icmp redirect nastává z kteréhokoli zařízení z LAN spojujícíse ho stelefonem (hypoteticky jako kdybymi tam jel webserver):
(z pohledu phonu)
10.5.0.VPS > 10.5.0.PHONE ICMP REdirect 192.168.1.22 to HOST 10.5.0.NATEDROUTER
(z pohledu NATEDROUTERU)
---žádný redirect---
(z pohledu vps)
10.5.0.VPS > 10.5.0.PHONE: ICMP redirect 192.168.1.22 to host 10.5.0.NATEDROUTER, length 48
IP (tos 0x0, ttl 63, id 37, offset 0, flags [DF], proto TCP (6), length 40)
10.5.0.PHONE.88 > 192.168.1.21.51607: Flags
- , cksum 0x5d2b (correct), seq 0, ack 2207791321, win 0, length 0
NAT se mezi těmito sítěmi neděje. (NAT dělá jenom vps pří přístupu na internet nebo router při přístup na internet přes WAN)
záznam flow při nc 10.5.0..PHONE 80:
00:00:00.000000 IP 192.168.1.21.52247 > 10.5.0.PHO.8222: Flags [S], seq 2572734474, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1123288837 ecr 0,sackOK,eol], length 0
00:00:00.000022 IP 192.168.1.21.52247 > 10.5.0.PHO.8222: Flags [S], seq 2572734474, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1123288837 ecr 0,sackOK,eol], length 0
00:00:00.771971 IP 10.5.0.PHO.8222 > 192.168.1.21.52247: Flags [R.], seq 0, ack 2572734475, win 0, length 0
00:00:00.000024 IP 10.5.0.VPS > 10.5.0.PHO: ICMP redirect 192.168.1.21 to host 10.5.0.NATEDROUTER, length 48
00:00:00.000012 IP 10.5.0.PHO.8222 > 192.168.1.21.52247: Flags [R.], seq 0, ack 1, win 0, length 0(jo to vím, že některé knihovny střílí TCP syn x krát)
a z telefonu
00:00:00.000012 IP (tos 0xc0, ttl 64, id 32201, offset 0, flags [none], proto ICMP (1), length 80)
10.5.0.VPS > 10.5.0.PHO: ICMP redirect 192.168.1.16 to host 10.5.0.NATEDROUTER, length 60
IP (tos 0x0, ttl 63, id 43356, offset 0, flags [DF], proto TCP (6), length 52)
10.5.0.PHO.37549 > 192.168.1.16.80: Flags [F.], cksum 0x448a (correct), seq 76, ack 374, win 131, options [nop,nop,TS val 4303581 ecr 19382204], length 0A to nejduležitější: Nemám třeba blbě konfiguraci WG ? Mám to tak, že VPS má 2 peery (router, phone), ale PHONE má peera VPS a ROUTER má peera VPS taky (ostatně jak jinak)?
čili co je to za věc? je to nějaký bug vážnž'ý? nebo je to očekáváné chování? vypadá, to ,že telefon posílá pakety jakousi špatnou pseudobránu (ale pochybuju, že něco takového existuje v TUN) . opakuju, že vše funguje. Jenom prostě padají z obou směrů tyhle ICMP zdvižené prsty
Je to asi takhle? On by ten VPS chtěl, aby to WG bylo spojené do trojúhelníka (propojit PHONE a router) ale to nejde, protože nikdo z nich nemá veřejnou IP ... proto pořád vysílá ty icmp redirecty... Mezi nimi musí být ten styčný VPS
A teď, jak to řešit? něco správně dokonfigurovat (a kde) nebo umlčet logy (nějaké sysctl) nebo ignorovat nebo upgradovat nějakého wg démona
40 Odpovědí
6202 Zhlédnutí