Mikrotik és wireguard hiba

Hálózati eszközök

Sziasztok! Az alábbi konfiggal egy ideig ment a vpn az otthoni lanom és az iphone-om között, akkor "ment el" valami, amikor próbáltam a pop os-t futtató laptopomon is belőni a wireguardot. Visszatettem egy backupot a routerre, amin korábban tutira jól ment a wg a router és a teló között, de sajnos nem oldódott meg ettől a helyzet. Itt a konfig, hátha valami sasszemű kiszúr benne valamit:

 /ip firewall filter print        
Flags: X - disabled, I - invalid; D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; Wireguard
      chain=input action=accept protocol=udp in-interface=pppoe-out1 dst-port=51820 log=no log-prefix="" 

 2    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 3    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 4    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 5    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

 6    chain=input action=accept protocol=udp in-interface=wireguard1 dst-port=51820 log=no log-prefix="" 

 7    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN 

 8    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

 9    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

10    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related 

11    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

12    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

13    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN 
 

 

/ip firewall nat print           
Flags: X - disabled, I - invalid; D - dynamic 
 0    ;;; Hairpin NAT
      chain=srcnat action=masquerade src-address=192.168.88.0/24 dst-address=192.168.88.0/24 log=no log-prefix="" 

 1    ;;; Hairpin NAT for WireGuard
      chain=srcnat action=masquerade src-address=10.10.10.0/24 dst-address=192.168.88.0/24 

 2    ;;; Home Assistant, Forwarding port 80 to HA ip
      chain=dstnat action=dst-nat to-addresses=192.168.88.3 protocol=tcp in-interface=pppoe-out1 dst-port=80 log=no log-prefix="" 

 3    ;;; Home Assistant, Forwarding port 443 to HA ip
      chain=dstnat action=dst-nat to-addresses=192.168.88.3 protocol=tcp in-interface=pppoe-out1 dst-port=443 log=no log-prefix="" 

 4    ;;; Home Assistant catch-all
      chain=dstnat action=dst-nat to-addresses=192.168.88.3 dst-address-list=WAN log=no log-prefix="" 

 5    ;;; Home Assistant source NAT fix
      chain=srcnat action=src-nat to-addresses=185.180.88.194 src-address-list=WAN log=no log-prefix="" 

 6    ;;; Masquarade from WireGuard
      chain=srcnat action=masquerade src-address=10.10.10.0/24 out-interface-list=WAN log=no log-prefix="" 

 7    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none 
 

 

/interface wireguard print detail
Flags: X - disabled; R - running 
 0  R name="wireguard1" mtu=1412 listen-port=51820 private-key="=" public-key="=" 

 

/interface wireguard peers print detail                                                                                                      
Flags: X - disabled; D - dynamic 
 0    interface=wireguard1 name="telefon" public-key="=" private-key="" endpoint-address="" endpoint-port=0 current-endpoint-address="" current-endpoint-port=0 allowed-address=10.10.10.2/32 
      preshared-key="" client-endpoint="" rx=0 tx=0 

 1    interface=wireguard1 name="laptop" public-key="=" private-key="" endpoint-address="" endpoint-port=0 current-endpoint-address="" current-endpoint-port=0 allowed-address=10.10.10.3/32 
      preshared-key="" client-endpoint="" rx=0 tx=0 

 

/interface list member print                                                                                   
Columns: LIST, INTERFACE
# LIST  INTERFACE 
;;; defconf
0 LAN   bridge    
;;; defconf
1 WAN   ether1    
2 WAN   pppoe-out1
3 LAN   wireguard1
 

 /tool sniffer quick port=51820                                                                                                               
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE   TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS         DST-ADDRESS           PROTOCOL  SIZE  CPU
bridge      4.654     2  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      4.654     3  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  9.416     4  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      9.416     5  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      9.416     6  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  14.628    7  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      14.628    8  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      14.628    9  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  19.769   10  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      19.769   11  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      19.769   12  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  24.882   13  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      24.882   14  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      24.882   15  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  30.159   16  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      30.159   17  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      30.159   18  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
pppoe-out1  35.336   19  <-                                         37.76.11.127:34758  185.180.88.194:51820  ip:udp     176    3
bridge      35.336   20  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
ether5      35.336   21  ->   D4:01:C3:3D:8E:DB  02:4D:B7:CE:D2:3A  37.76.11.127:34758  192.168.88.3:51820    ip:udp     190    3
 

Ha kell még valami, akkor megnézem. Előre is köszönök minden segítséget. Ja és az olyan triviális körökön túl vagyok, mint hogy a kulcsok jók -e, portok egyeznek -e, engedélyezett ip-k, jók -e.

Márk

  • 772 megtekintés

( dorsy v | 2025. 08. 04., h – 18:37 )

jol latom, h benatolod valami random belso ip-re a WG portjat? :) mert szerintem ott van elszabva a dolog.

( mark82 | 2025. 08. 04., h – 18:43 )

Szerkesztve: 2025. 08. 04., h – 18:48

Annyi van, hogy a helyi hálón futó szervereket el kell érnem a domain nevükkel is, nem csak az ip-jükkel. Ment így, nem zavarta.

szerk.: a móka kedvéért kilövöm.

szerk 2: semmi hatása nem volt a nat hairpin letiltásának

( ggallo | 2025. 08. 04., h – 19:02 )

Szerkesztve: 2025. 08. 04., h – 19:05

Nekem fura ezen a sniffer részleten, hogy a forrás cím publikus, sem nem 192.168.88.x  sem nem 10.10.10.x, és tippre a bridge és az ether5 is a LAN része, egyik sem internet oldali port. A válasz így a pppoe-out1-en kimegy az internetre, nem a kezdeményezőhöz jut vissza. Miért kommunikál publikus címmel a belső hálózaton az eszköz?

Ha nem ez a gond forrása, akkor egyébként a legtöbbször a publikus kulcsokon csúszik el a WG konfig. Azt ellenőrizd le, hogy mindenkinél, minden pozícióban jók-e a kulcsok.

Meg a konfig részletből nem látszik, van-e a WG interfésznek IP címe. Erről még győződj meg, jó-e (van-e és /32-nél nyitottabb-e a maszkja pl.).

A problémától függetlenül: a belső gépeknek FQDN-es elérést belső szolgáltatáshoz praktikusabb split DNS-sel megoldani. Ugyanis hairpin NAT esetében a forrás cím "elveszik", ha LAN-ról jön a forgalom, így a szerver log-ban csak egy csomó router IP-s kapcsolódást látsz, nem tudod melyik melyik klienstől származik. Míg split DNS-nél a belső kliensek valódi címét látod a szerberen is. Mikrotik-kel meg pofon egyszerű ezt megcsinálni.

Szerk: WG interfészt érdemesebb még alacsonyabb MTU-val futtatni. Nálunk az 1300 vált be univerzálisnak (hogy ne kelljen mindenhol kiszámolni, mi a max), ami nagyjából mindenféle internet kapcsolat MTU-val jól működik. Ilyen "magas" MTU-val lesz ami nem tud érdemben válaszolni, hiába működik mondjuk a ping az adott címre.

Szia, köszönöm a választ!

- igen, az, hogy külső ip-vel kommunikál a belső hálóan, egy jogos meglátás, nem tudom, hogy mi okozza, de valszeg ez a baj forrása

. újra végignyálazom a kulcsokat

- a wg ip címe 10.10.10.1/24

- veszek egy nagy levegőt és megcsinálom a split dns-t

- már át is állítottam 1300-ra

Próbáld a laptopot feléleszteni elsőre (az valószínű nem rendelkezik publikus IP címmel, hacsak nincs abban is WWAN kártya), vagy tiltsd le a telefonon a mobilnetet (hogy ne legyen publikus IP címe semmiképp sehonnan).

Ha úgy működik, akkor azt kell kitalálnod, a telefon miért publikus IP címmel akar kommunikálni az otthoni (gondolom Wifi) hálózatodon. Azt meg észre sem veszed, hogy nem a Wifi-n netezik a teló, hanem mobilneten (merthogy így az internet sem a vezetékes kapcsoladoton megy a telefon esetében, nem csak a WG kapcsolatnál okoz ez gondot).

Kikapcsolt mobilnetnél létrejön a handshake:

/tool sniffer quick port=51820
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE  TIME       NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS           DST-ADDRESS           PROTOCOL  SIZE  CPU
ether5     102.52   39721  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
bridge     102.52   39722  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
bridge     102.562  39723  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     154    3
ether5     102.562  39724  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     154    3
bridge     102.562  39725  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     102.562  39726  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     102.566  39727  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
bridge     102.566  39728  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
ether5     102.566  39729  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
bridge     102.566  39730  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
ether5     102.566  39731  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
bridge     102.566  39732  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     122    1
bridge     103.274  39733  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     103.274  39734  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     103.339  39735  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
bridge     103.339  39736  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
bridge     103.496  39737  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     103.496  39738  ->   D4:01:C3:3D:8E:DB  12:1A:3F:01:A7:18  185.180.88.194:51820  192.168.88.63:64548   ip:udp     138    3
ether5     103.577  39739  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
bridge     103.577  39740  <-   12:1A:3F:01:A7:18  D4:01:C3:3D:8E:DB  192.168.88.63:64548   185.180.88.194:51820  ip:udp     138    1
 

Viszont itt sem a wireguard-os ip címen kommunikál, ami a 10.10.10.2

( Imo | 2025. 08. 04., h – 19:22 )

 ;;; Home Assistant source NAT fix
      chain=srcnat action=src-nat to-addresses=185.180.88.194 src-address-list=WAN log=no log-prefix="" 

 

Ezmi? Bármi ami a wan oldalról jön, az megy a .88.194-re, wireguard forgalmat is beleértve.

Szerintem hiába van input szabály a wireguard porta, ez előbb benatolja belülre és nem is kapja meg a mikrotik wireguard-ja.

Próbálj meg minden nem default config szabályt letiltani kivéve az inputot a wireguardnak, meg persze winbox-ot, hogy ki ne zárd magad. (különösen a harpin őrületeket szedd ki)

Vagy csinálj egy reset-et és kezd elölről, mert valami más is el van állitva.

Vagy dobj be egy teljes exporot, ha anonimizáltad.

Ami a Mikrotik-nek szól (MT IP címe a címzett ergo bekerül az input chain-be) és input-on be van engedve, és van is rajta szolgáltatás helyben, azt a MT lekezeli, nem NAT-olja befelé akkor sem, ha egy szabály azt lefedi.

Pl. 8291-en input-on engeded a Winbox-ot és van is Winbox ezen a porton (gyári default), és van egy DSTNAT, ami minden, az internet interfészen jövő forgalmat beNATol egy belső "szerverre", Winbox-on akkor is a Mikrotik lesz elérhető.

A szabályok letiltása után, teló 5g-n, wifi kikapcsolva  és megy a wireguard:

/tool sniffer quick port=51820
Columns: INTERFACE, TIME, NUM, DIR, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE   TIME    NUM  DIR  SRC-ADDRESS           DST-ADDRESS           PROTOCOL  SIZE  CPU
pppoe-out1  1.748     1  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp      60    3
pppoe-out1  2.925     2  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp      60    0
pppoe-out1  3.271     3  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     460    0
pppoe-out1  3.271     4  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  3.284     5  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  3.285     6  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     108    3
pppoe-out1  3.327     7  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     124    3
pppoe-out1  3.446     8  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     204    3
pppoe-out1  3.446     9  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     620    3
pppoe-out1  3.446    10  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     172    3
pppoe-out1  3.447    11  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp     620    3
pppoe-out1  3.49     12  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  3.491    13  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  4.272    14  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  5.266    15  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  6.284    16  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  7.313    17  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  8.312    18  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  10.311   19  <-   37.76.29.151:50120    185.180.88.194:51820  ip:udp     124    0
pppoe-out1  13.908   20  ->   185.180.88.194:51820  37.76.29.151:50120    ip:udp      60    3

( mark82 | 2025. 08. 04., h – 20:34 )

Szerkesztve: 2025. 08. 04., h – 20:48

szerk.: átraktam a helyére

( pidro | 2025. 08. 04., h – 20:56 )

Hat en regebben probaltam 2 kliensel egyszerre csatlakozni ugyanarra wireguard port-ra de valahogy mindig elbacodott es akkor latam hogy masnak volt ezzel gondja es megoldas az volt hogy minden eszkoz kulon port. De mintha azt olvastam volna hogy ez a hiba mar javitva lett. Egy probat meger.

Ha jól értem a működését, akkor egy wireguard-nak egy listen portja van és azért az fura lenne, ha minden egyes csatlakoztatandó eszköznek egy másikat kéne futtatni. Igazából letiltottam a második eszközt (laptopot), csak a telefon maradt, szóval ha nem barmolt el valamit végérvényesen az, hogy a laptopot bekonfiguráltam, akkor most biztosan nincsenek összeveszve.

Csak olyankor fordul ez elő, ha ugyan azt a kliens konfigot felteszik több kliensre és azok egyszerre akarnak kommunikálni, ugyan azzal a privát/publikus kulcs párral. Akkor nem tudja megkülönböztetni a fogadó oldal, hogy kicsoda-kicsoda, és egyik kapcsolat sem fog működni.

WG-nál szigorúan minden kliensnek saját privát- és így publikus kulcs kell.

Akkor jó a több WG interfész (mint minden más VPN megoldásnál), ha különböző célokra, különböző korlátozásokkal szerenél több VPN-t egy időben. Pl. van site2site kapcsolat telephelyek felé és van home office-ból szóló kliens is. Ezeket célszerű két független VPN "szerverre" szétbontani (azért az idézőjel, mert a WG peer2peer, nincs dekikált szerver és dedikált kliens, max. kényszeríthető, hogy az egyik oldal csak válaszoljon, ne kezdeményezzen).

Olyan hibát láttam, hogy /32 helyett teljes subnetet (allowed-address vagy allowedips) odaadták minden kliensnek és a legutuljára csatlakzóé lett a forgalom. Linuxon is így állította be a kolléga, de ott valsz benyeli valami a problémát és a logikátlan konfiggal is működik. A routeros-en jogosnak tűnt, hogy a /32 kell neki, ha nem komplett alhálózatot akarok neki odaadni. A mostani topicban is ezt néztem először meg :)

A másik porttal gondolom több példányban futtattál külön wireguardot.

( Z0l v | 2025. 08. 05., k – 08:10 )

Van mar amugy "gyari" wireguard opcio is a mikrotiknel, ez a back to home es egesz jol mukodik. Megcsinalja a szukseges szabalyokat + ad egy relay-t ha mindket vegpontnak privat ip cime van is tudjanak kapcsolodni.

+1

A config exportálható Wireguard kliens alá is, nem kell Mikrotik-es kliens hozzá (bár Windows alá jó lenne valami, mert a Wireguard kliens ott nagyon mostoha jószág), szerencsére nem sokat mókoltak a Wireguarddal (nem olyan májkrémszaftosan értelmezték át "de azértis" szabvány keretében :D )

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( mark82 | 2025. 08. 05., k – 09:19 )

Szóval a wg megy és ez örömteli, csak az a gondom, hogy a nat szabályok hiányában a belső hálóról domain néven nem elérhetőek a szervereim. Ez végülis túlmutat a topic címén, mindenesetre mindenkinek nagyon köszönöm az ötleteket, segítséget! :)

 

Azért csak megkérdezem: ha a /ip dns static add name=https://szerverem.hu address=192.168.88.3 csak az nginx-re mutat, merthogy sajnos portot nem lehet megadni,akkor a reverse proxyn belül hogyan kéne megoldanom, hogy ő a megfelelő portra küldje a forgalmat? Ezen az ip-n jelenleg 6 szerver fut.

A DNS static-hoz csak az FQDN-t kell írni (tehát a szerverem.hu a https:// nélkül), és ha ezt a nevet a kliens feloldja a MT-en keresztül a 192.168.88.3 címre, akkor minden kérést, amit a szerverem.hu-ra küld, erre a belső címre fogja továbbítani, tehát DNS szinten nincs port meg ilyesmi, ez teljesen más területe a kommunikáció felépítésének.

Az, hogy minden FQDN-ed forgalma a belső hálózatról erre a címre menjen csak annyi, hogy minden FQDN-hez felveszel egy-egy A rekordot, és megadod ugyan ezt a címet hozzá. Akkor minden saját tartományra irányuló kérés bentről ugyan arra a szerveredre (reverse proxy) fog menni.

Aztán az nginx konfigban tudod szétszortírozni, hogy milyen FQDN-t milyen tényleges belső szerver felé továbbítson, milyen porton. Ha felteszel egy Nginx Proxy Manager-t, akkor ott mindezt kényelmesen egy webes admin felületen tudod bállítani, nem kell az nginx konfigot kézzel írogatnod. Sőt, a Let's Encrypt tanúsítványt is intézi neked automatikusan. Ez létezik Docker konténerként és Proxmox CT-ként is az egyszerű telepítés végett.

Rendben. Megcsináltam az A rekordokat domain névvel pl. joplin.sajatdomain.hu és az 192.168.88.3-ra irányítottam, azaz a már meglévő nginx proxy managerhez. Ezt amúgy home assistant add-onként futtatom. Mind a hat domannel megcsináltam az előbb leírtat, minden az 192.168.88.3-ra mutat. Az nginx-ben proxy hostként már meg voltak ezek a bejegyzések, ide irányított a catch-all szabály is.

A telefonomon a wireguard appban a peer dns szerver címét módosítottam 192.168.88.1-re. A telefonról pingelhető az 192.168.88.1, még sincs névfeloldás. Átmenetileg a wireguard-ot érintő nat szabályt is engedélyeztem, de ettől sem lett. Mit kéne átállítanom?

 

/ip dns print
servers: 1.1.1.1        
              8.8.8.8        
dynamic-servers: 185.106.112.70 
                            185.106.112.170

use-doh-server:                
verify-doh-cert: no             
doh-max-server-connections: 5              
doh-max-concurrent-queries: 50             
doh-timeout: 5s             
allow-remote-requests: yes            
max-udp-packet-size: 4096           
query-server-timeout: 2s             
query-total-timeout: 10s            
max-concurrent-queries: 100            
max-concurrent-tcp-sessions: 20             
cache-size: 2048KiB        
cache-max-ttl: 1w             
address-list-extra-time: 0s             
vrf: main           
mdns-repeat-ifaces:                
cache-used: 157KiB         
 

/ip dhcp-server network print
Columns: ADDRESS, GATEWAY, DNS-SERVER
# ADDRESS          GATEWAY       DNS-SERVER  
;;; defconf
0 192.168.88.0/24  192.168.88.1  192.168.88.1

/ip dns static print
Flags: X - DISABLED
Columns: NAME, TYPE, ADDRESS, TTL
#   NAME                        TYPE  ADDRESS       TTL
;;; defconf
0   router.lan                  A     192.168.88.1  1d 
1   a.sajat.hu  A     192.168.88.3  1d 
2   b.sajat.hu    A     192.168.88.3  1d 
3   c.sajat.hu   A     192.168.88.3  1d 
4   d.sajat.hu     A     192.168.88.3  1d 
5   e.sajat.hu   A     192.168.88.3  1d 
6   f.sajat.hu       A     192.168.88.3  1d

nslookup-al nézd meg egy gépen (ne telefonon) hogy ha a szervert a mikrotikre állitod (azon az ip-n amit a wg configban felvettél dns-ként) feloldja-e a belsős cimeket. (a gép is "kivül" legyen, wg-al csatlakozzon be a mikrotikre)

Ha igen, akkor a telefonos wg kliens a hülye és nem a jó dns szervert kérdezi.

Ha nem, akkor lehet tovább kutakodni a mikrotik-en.

Ha jól értem, akkor eleve ezt használom. De lehet, hogy félreértettem a dolgot:

/ip dns static print
Flags: X - DISABLED
Columns: NAME, TYPE, ADDRESS, TTL
#   NAME                        TYPE  ADDRESS       TTL
;;; defconf
0   router.lan                  A     192.168.88.1  1d 
1   a.sajat.hu  A     192.168.88.3  1d 
2   b.sajat.hu    A     192.168.88.3  1d 
3   c.sajat.hu   A     192.168.88.3  1d 
4   d.sajat.hu     A     192.168.88.3  1d 
5   e.sajat.hu   A     192.168.88.3  1d 
6   f.sajat.hu       A     192.168.88.3  1d

 

Nginx proxy manager-ben pedig mindegyik megkapja a maga portját, nyilván ugyanazon ip alatt. Így értetted?