Nejsem na Wireguard úplný odborník a ani se v tom moc do hloubky hrabat nechci, ale mám teď čerstvou zkušenost s Wireguard na Mikrotiku a ze sledování vidím, že Wireguard zkouší navázat spojení vždy, když je nějaký packet routován směrem k tomu peeru. Peer se buď volí podle Allowed address nebo pokud je 0.0.0.0/0, tak tam posílá vše - zde je problém pokud je nad jedním wireguard interface více peeru s 0.0.0.0/0, pak to nefugnuje, je tedy třeba mít co interface a listen port = to jeden tunel na jiné zařízení.
Klienty mám připojené přes LTE od TMobile a docela tam dělá problémy jejich CGNAT, za kterým mají ty maloobchodní data schovaná. Prakticky po každém resetu LTE nebo přepojení na jinou cellu to dostane novou IP adresu na interface, což vede k tomu, že se změní veřejka + srcport za který to schovává CGNAT a implementace Wireguard v Mikrotik si s tímto nedokáže poradit a komunikace zcela přestane fungovat. Jediný workaround je, že jsem tam udělal netwatch, který když shodí/nahodí wireguard peer, což vede k vyčištění klíčů u spojení a teprve pak se komunikace rozjede. Avšak co jsem tohle googloval, Linuxová implementace by tohle měla mít dnes opraveno. To LTE je vždy jen jako záložní linka, takže mě to zatím netrápí natolik, abych zkusil na straně serveru Mikrotik vyměnit za čistý Linux, jestli to bude dělat to samé nebo ne. Tenhle problém by taky vyřešila podpora IPv6, ale rámcovka je s TM a ten dnes jako jediný IPv6 na LTE neumí...
Chápu, že informace jsou to k ničemu, ale možná to v tom Linuxu zas tak opravené není a možná to alespoň nasměruje nějaký směr, kde pátrat.