Bonjour à tous,

Edit : Problème résolu : tutoriel à venir

Tuto à venir : https://lafibre.info/mikrotik/tuto-acceder-a-service-auto-heberge-en-4g-via-vps-et-wireguard-sur-mikrotik/

Je me permets de solliciter votre aide concernant un problème de redirection de port avec ma configuration VPN WireGuard, VPS et routeur MikroTik. Je vous décris ci-dessous les détails de ma configuration et quelques une des étapes que j'ai déjà tentées pour résoudre le problème.

Mon objectif :

Lorsque ma fibre est en panne je souhaite que mes services https sur mon synology soit accessible via l'IP du VPS et non plus depuis mon ip standard fibre

Configuration actuelle :

J'ai un routeur MikroTik CCR2116 (RouterOS v7.9b rc3) connecté à une fibre Orange sur un port sfp4 et accessible à mon LAN via br-wan (config de Gnubyte) de ce coté là tout est OK.
En parallèle, j'ai une connexion 4G sur un Modem Netgear L1200 (son interface est accessible via mon lan à l'adresse 192.168.5.1) configuré en mode pont qui délivre donc a mon routeur Mikrotik une adresse de type 10.X.X.X via le reseau d'Orange. De ce coté là tout est OK. Coté Synology le par-feu est désactive.

Par ailleurs j'ai un VPS OVH qui fait office de serveur WireGuard. Le VPS possède une interface publique (ens3) et une interface VPN WireGuard (wg0).
Mon routeur MikroTik (RouterOS v7.9b rc3) est configuré pour établir une connexion VPN avec le serveur WireGuard sur mon VPS. L'interface WireGuard sur le routeur MikroTik est appelée "wireguard".

Topo reseau:

90.X.X.X Mon WAN - WAN Fibre Orange
10.X.X.X                - WAN 4G Orange - Modem LM1200 en pont
215.X.X.X              - IP Publique VPS
192.168.1.0/24      - LAN
192.168.1.50         - Synology NAS
192.168.5.1           - GUI modem LM1200
192.168.100.0/24   - Mon VPN WireGuard
192.168.100.100    - IP de l'interface WireGuard - VPS Server OVH
192.168.100.105    - IP de l'interface WireGuard - Mikrotik



Test ping depuis mon Mikrotik en 4G vers VPS

ping 8.8.8.8
    0 8.8.8.8                                    56 110 41ms542us
    1 8.8.8.8                                    56 110 38ms769us
    2 8.8.8.8                                    56 110 28ms738us ping 192.168.100.105

ping 192.168.100.100
    0 192.168.100.100                            56  64 34ms443us
    1 192.168.100.100                            56  64 42ms655us
    2 192.168.100.100                            56  64 37ms27us   

Test ping depuis mon VPS (vers Mikrotik en 4G - fibre désactive)

ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=4.80 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=111 time=4.86 ms

ping 192.168.100.105
64 bytes from 192.168.100.105: icmp_seq=1 ttl=64 time=51.1 ms
64 bytes from 192.168.100.105: icmp_seq=2 ttl=64 time=30.0 ms
64 bytes from 192.168.100.105: icmp_seq=3 ttl=64 time=49.3 ms

ping 192.168.1.1
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=46.2 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=44.2 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=43.0 ms

ping 192.168.1.50
64 bytes from 192.168.1.50: icmp_seq=1 ttl=63 time=42.0 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=63 time=40.8 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=63 time=40.7 ms


Vérification ouverture de port (depuis le VPS)

root@vps:/etc/wireguard# nc -zv 192.168.1.50 80
Connection to 192.168.1.50 80 port [tcp/http] succeeded!
root@vps:/etc/wireguard# nc -zv 192.168.1.50 443
Connection to 192.168.1.50 443 port [tcp/https] succeeded!

Vérification ouverture de port (depuis mon Mac sur un autre reseau - sans WireGuard)

monMac: nc -zv IP_VPS 80
#Aucune réponse
monMac: nc -zv  IP_VPS 443
#Aucune réponse



Mon fichier wg0.conf (VPS)

root@vps:/etc/wireguard# cat wg0.conf
[Interface]
Address = 192.168.100.100/24
SaveConfig = true
ListenPort = 51820
PrivateKey = Ma PrivateKey
DNS = 9.9.9.9
[Peer]
PublicKey = Ma PublicKey
AllowedIPs = 192.168.1.0/24, 192.168.100.0/24
Endpoint = IP:13231 #Lorsque ma fibre est OK ip fibre mais si 4G ip qui mets inconnu
PersistentKeepalive = 120

J'ai configuré des règles de redirection de port sur mon VPS en utilisant iptables pour rediriger le trafic entrant vers des machines spécifiques sur mon réseau local (par exemple, 192.168.1.50 et 192.168.1.105) pour les ports 80, 443 et 32400.
J'ai également configuré des règles de pare-feu (srcnat) sur mon routeur MikroTik pour autoriser le trafic entrant et sortant via le VPN WireGuard.
cf : ufw show raw.txt

Problème rencontré :

La redirection de port ne semble pas fonctionner correctement. Lorsque j'essaie d'accéder à mes services locaux à distance via l'IP du VPS (par exemple, un serveur web sur le port 443) mon nom de domaine, je n'obtiens pas de réponse. (J'ai bien sur changer mon IP fibre par mon ip VPS coté nom de domaine OVH)

Étapes déjà tentées pour résoudre le problème :

J'ai vérifié les règles de redirection de port sur mon VPS en utilisant la commande sudo iptables -t nat -L PREROUTING --line-numbers -n -v. Les règles semblent correctes et redirigent le trafic vers les bonnes adresses IP locales et les ports associés.

root@vps-67ff5caf:/etc/wireguard# iptables -t nat -L PREROUTING --line-numbers -n -v
Chain PREROUTING (policy ACCEPT 4071 packets, 158K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       28  1410 DNAT       tcp  --  ens3   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:192.168.1.50:80
2       17   772 DNAT       tcp  --  ens3   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:192.168.1.50:443
3        2    80 DNAT       tcp  --  ens3   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:32400 to:192.168.1.50:32400

J'ai examiné les journaux de mon routeur MikroTik pour vérifier les connexions sortantes et entrantes via l'interface WireGuard. Les connexions semblent être acheminées correctement via le VPN, et aucune erreur ou activité suspecte n'a été détectée. Toutefois, j'ai remarqué que les connexions TCP (SYN) vers les adresses IP externes semblent ne pas aboutir.


Voici quelques exemples de règles iptables et de journaux MikroTik pour vous donner une meilleure idée de ma configuration actuelle :

[Gael@MikroTik] > /ip/firewall/filter/print
Flags: X - disabled, I - invalid; D - dynamic
 0    ;;; Accept established and related connections
      chain=input action=accept connection-state=established,related

 1    ;;; Accept ICMP (ping)
      chain=input action=accept protocol=icmp

 2    ;;; Accept DNS TCP
      chain=input action=accept protocol=tcp in-interface=all-ethernet
      port=53

 3    ;;; Accept DNS UDP
      chain=input action=accept protocol=udp in-interface=all-ethernet
      port=53

 4 X  ;;; Drop all other traffic
      chain=input action=drop in-interface=all-ethernet log=no log-prefix=""


[Gael@MikroTik] > /ip/firewall/nat/print
Flags: X - disabled, I - invalid; D - dynamic
 0    ;;; Permet de faire sortir le traffic via Fibre
      chain=srcnat action=masquerade to-addresses=0.0.0.0
      out-interface=br-wan log=no log-prefix=""

 1    ;;; Permet de faire sortir le traffic via WireGuard - VPS
      chain=srcnat action=masquerade to-addresses=0.0.0.0
      out-interface=wireguard log=yes log-prefix="WG"

 2    ;;; Permet de faire sortir le traffic via 4G
      chain=srcnat action=masquerade to-addresses=0.0.0.0
      out-interface=ether2-4G log=no log-prefix=""

 3 X  chain=srcnat action=accept out-interface=ether2-4G log=no log-prefix=""

 4 X  chain=dstnat action=accept in-interface=ether2-4G log=yes log-prefix=""

 5    ;;; HairpinNAT - IP WAN vers https Synology
      chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=443
      protocol=tcp dst-address=90.X.X.X dst-port=443 log=no log-prefix=""

 6    ;;; HairpinNAT - Masquarade Reseau local vers Synology
      chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/24
      dst-address=192.168.1.50 out-interface=sfp4-LAN log=no log-prefix=""

 7    ;;; Synology port http entrant & sortant
      chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=80
      protocol=tcp in-interface=wireguard dst-port=80 port="" log=yes
      log-prefix="http synoW"

 8    ;;; Synology Port https entrant et sortant
      chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=443
      protocol=tcp in-interface=wireguard dst-port=443 log=yes
      log-prefix="https synoW"

 9    ;;; Synology port http entrant & sortant
      chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=80
      protocol=tcp in-interface=br-wan port=80 log=no log-prefix="http syno"

10    ;;; Synology Port https entrant et sortant
      chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=443
      protocol=tcp in-interface=br-wan port=443 log=no
      log-prefix="https syno"
 

Haha trop bien, ce type de post est justement la raison pour laquelle j'ai argumenté la création de cette section.

Si je comprends bien, tu tiens à rendre l'accessibilité de tes services résiliente à la perte de l'un ou l'autre de tes liens, en utilisant un serveur virtuel chez OVH dont l'adresse IP est fixe, comme IP externe de tes services, hébergés chez toi derrière le routeur mikrotik lequel est connecté à internet via soit la fibre FTTH, soit le lien 4G Netgear en mode pont, avec un lien Wireguard dessus.

Charge ensuite au routeur de basculer sur l'un ou l'autre lien, mais que les services soient toujours visibles depuis internet.

Je paraphrase, et tu me corriges si je me trompe, mais en gros c'est ça ton objectif ?

Oui c’est exactement ça :

L’idée étant que si la Fibre est down alors mes service transite via WireGuard est soit accessible via l’IP du VPS,
Et si la fibre est Up alors que tout soit accessible depuis l’IP Fibre …

Mais pour le moment je n’ai pas réussi … impossible d’accéder à mes services via le VPS au travers du tunnel WireGuard

Tout début de piste est bienvenue, et merci à toi Gnubyte !

En gros, quand tu retires (ou désactive) la fibre orange, que tu utilises l'IP du VPS, ça ne marche pas alors pour pour toi tout est ok niveau connexion ?

Qu'as-tu comme route par défaut sur ton mikrotik lorsque la fibre est down ?
Il faut que ta route par défaut pointe vers le wireguard, sinon ton flux retour sera ko (tu vas voir ton syn arriver depuis le wg mais ton routeur ne saura pas vers qui le renvoyer en absence de route).

A moins que ce soit précisé dans ton post (désolé je pas regardé toute la conf), je suppose qu'il faut ajouter une route statique de type 0.0.0.0 vers ton wg et un poid plus elevé (genre 10 ou 20) que ta route par défaut habituelle.
Ainsi, si ta route par défaut tombe (ton accès fibre), la route statique prendra le relais et saura où renvoyer ton traffic (via le wg).

Edit: Bon apparemment c'est le cas
Quand tu désactives la fibre, la route par défaut est bien supprimée ?
Peux-tu faire une capture sur le mikrotik avec la fibre désactivé ? Le SYN arrive bien et est transmis au serveur ? Répond-t-il ? Le SYN ack est bien renvoyé sur le wireguard ?
Quand je vois ta table de routage, on dirait que pour le retour ton paquet va utiliser la route de poid 1 et donc utiliser le canal en clair et pas via wg. J'aurai pas mis un deuxième route pas défaut en clair mais uniquement la deuxième route de poids 2 et une route statique pour contacter l'IP de ton VPS afin que le WG se monte.

Voici les capture d'écran des route avec la fibre désactive) => Interface br-wan désactive.

Comment vérifier que "le SYN arrive bien et est transmis au serveur ? Répond-t-il ? Le SYN ack est bien renvoyé sur le wireguard ?"

Quand tu fais un ping depuis ton VPS vers ton Synology, ce n'est pas représentatif car l'interface wg de ton VPS est vue comme directement connectée sur ton mikrotik.

Tu devrais refaire ton test de redirection (un pc depuis internet) et faire une capture sur ton mikrotik/vps pour voir comment se passe le routage.

Par exemple sur ton VPS, un simple tcpdump sur l'interface wg0 devrait déjà nous montrer si ton trafic emprunte bien le wireguard :
tcpdump -ni wg0

Pareil un capture à base de sniffer sur le mikrotik devrait nous en dire plus.

Tout ça ressemble à un problème de routage tout de même.

Edit : Sur ta dernière capture on voit que le trafic arrive bien sur le mikrotik. C'est quoi comme règle https synoW ?

Quand tu fais un ping depuis ton VPS vers ton Synology, ce n'est pas représentatif car l'interface wg de ton VPS est vue comme directement connectée sur ton mikrotik.

Tu devrais refaire ton test de redirection (un pc depuis internet) et faire une capture sur ton mikrotik/vps pour voir comment se passe le routage.

Par exemple sur ton VPS, un simple tcpdump sur l'interface wg0 devrait déjà nous montrer si ton trafic emprunte bien le wireguard :
tcpdump -ni wg0

Pareil un capture à base de sniffer sur le mikrotik devrait nous en dire plus.

Tout ça ressemble à un problème de routage tout de même.

Edit : Sur ta dernière capture on voit que le trafic arrive bien sur le mikrotik. C'est quoi comme règle https synoW ?

Depuis un pc sur un autre reseau j'ai essayé d'accéder a mon nom de domaine mais il la page ne s'ouvre pas.
J'ai bien essayé un sniff de l'interface wireguard mais tout reste vide (pas de racket )

Voila le tcp dump depuis le VPS quand j'essaie d'accéder a ma page web on voit bien qu'il y a du traffic qui transitent via le VPS ... Mais la page web ne s'affiche pas

Code: [Sélectionner]

root@vps-67ff5caf:/etc/wireguard# tcpdump -ni wg0 -v
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
11:48:14.867190 IP (tos 0x0, ttl 255, id 48254, offset 0, flags [none], proto UDP (17), length 60)
    192.168.100.105.5678 > 159.148.147.229.30000: UDP, length 32
11:48:14.912380 IP (tos 0x0, ttl 43, id 0, offset 0, flags [none], proto UDP (17), length 60)
    159.148.147.229.30000 > 192.168.100.105.5678: UDP, length 32
11:48:15.866670 IP (tos 0x0, ttl 64, id 40432, offset 0, flags [none], proto UDP (17), length 64)
    192.168.100.105.5678 > 8.8.8.8.53: 62278+ A? cloud.mikrotik.com. (36)
11:48:15.871395 IP (tos 0x80, ttl 115, id 12355, offset 0, flags [none], proto UDP (17), length 80)
    8.8.8.8.53 > 192.168.100.105.5678: 62278 1/0/0 cloud.mikrotik.com. A 159.148.147.229 (52)
11:48:34.036520 IP (tos 0x0, ttl 50, id 27347, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.28.64488 > 192.168.1.50.443: Flags [S], cksum 0xe708 (correct), seq 597740066, win 64240, options [mss 1380,sackOK,TS val 4239862303 ecr 0,nop,wscale 13], length 0
11:48:34.570807 IP (tos 0x0, ttl 50, id 50826, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.17.56652 > 192.168.1.50.443: Flags [S], cksum 0x6604 (correct), seq 410791932, win 64240, options [mss 1380,sackOK,TS val 3535509777 ecr 0,nop,wscale 13], length 0
11:48:35.078376 IP (tos 0x0, ttl 50, id 27348, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.28.64488 > 192.168.1.50.443: Flags [S], cksum 0xe2f7 (correct), seq 597740066, win 64240, options [mss 1380,sackOK,TS val 4239863344 ecr 0,nop,wscale 13], length 0
11:48:35.590259 IP (tos 0x0, ttl 50, id 50827, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.17.56652 > 192.168.1.50.443: Flags [S], cksum 0x6208 (correct), seq 410791932, win 64240, options [mss 1380,sackOK,TS val 3535510797 ecr 0,nop,wscale 13], length 0
11:48:37.127324 IP (tos 0x0, ttl 50, id 27349, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.28.64488 > 192.168.1.50.443: Flags [S], cksum 0xdaf6 (correct), seq 597740066, win 64240, options [mss 1380,sackOK,TS val 4239865393 ecr 0,nop,wscale 13], length 0
11:48:37.638242 IP (tos 0x0, ttl 50, id 50828, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.17.56652 > 192.168.1.50.443: Flags [S], cksum 0x5a08 (correct), seq 410791932, win 64240, options [mss 1380,sackOK,TS val 3535512845 ecr 0,nop,wscale 13], length 0
11:48:41.159385 IP (tos 0x0, ttl 50, id 27350, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.28.64488 > 192.168.1.50.443: Flags [S], cksum 0xcb36 (correct), seq 597740066, win 64240, options [mss 1380,sackOK,TS val 4239869425 ecr 0,nop,wscale 13], length 0
11:48:41.670250 IP (tos 0x0, ttl 50, id 50829, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.42.17.56652 > 192.168.1.50.443: Flags [S], cksum 0x4a48 (correct), seq 410791932, win 64240, options [mss 1380,sackOK,TS val 3535516877 ecr 0,nop,wscale 13], length 0
11:48:49.607037 IP (tos 0x0, ttl 50, id 2930, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.126.22316 > 192.168.1.50.443: Flags [S], cksum 0x81bd (correct), seq 3939566716, win 64240, options [mss 1380,sackOK,TS val 4248094908 ecr 0,nop,wscale 13], length 0
11:48:50.182727 IP (tos 0x0, ttl 50, id 5723, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.112.35158 > 192.168.1.50.443: Flags [S], cksum 0x1fe4 (correct), seq 2939755818, win 64240, options [mss 1380,sackOK,TS val 2505605952 ecr 0,nop,wscale 13], length 0
11:48:50.630430 IP (tos 0x0, ttl 50, id 2931, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.126.22316 > 192.168.1.50.443: Flags [S], cksum 0x7dbe (correct), seq 3939566716, win 64240, options [mss 1380,sackOK,TS val 4248095931 ecr 0,nop,wscale 13], length 0
11:48:51.206642 IP (tos 0x0, ttl 50, id 5724, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.112.35158 > 192.168.1.50.443: Flags [S], cksum 0x1be4 (correct), seq 2939755818, win 64240, options [mss 1380,sackOK,TS val 2505606976 ecr 0,nop,wscale 13], length 0
11:48:52.679396 IP (tos 0x0, ttl 50, id 2932, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.126.22316 > 192.168.1.50.443: Flags [S], cksum 0x75bd (correct), seq 3939566716, win 64240, options [mss 1380,sackOK,TS val 4248097980 ecr 0,nop,wscale 13], length 0
11:48:53.254454 IP (tos 0x0, ttl 50, id 5725, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.112.35158 > 192.168.1.50.443: Flags [S], cksum 0x13e4 (correct), seq 2939755818, win 64240, options [mss 1380,sackOK,TS val 2505609024 ecr 0,nop,wscale 13], length 0
11:48:56.711362 IP (tos 0x0, ttl 50, id 2933, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.126.22316 > 192.168.1.50.443: Flags [S], cksum 0x65fd (correct), seq 3939566716, win 64240, options [mss 1380,sackOK,TS val 4248102012 ecr 0,nop,wscale 13], length 0
11:48:57.286433 IP (tos 0x0, ttl 50, id 5726, offset 0, flags [DF], proto TCP (6), length 60)
    104.28.147.112.35158 > 192.168.1.50.443: Flags [S], cksum 0x0424 (correct), seq 2939755818, win 64240, options [mss 1380,sackOK,TS val 2505613056 ecr 0,nop,wscale 13], length 0
^C
20 packets captured
20 packets received by filter
0 packets dropped by kernel


Le SYN est envoyé mais pas de retour de ton Mikrotik.
Tu as un problème de routage côté Mikrotik.

EDIT: Pourquoi tu as une règle dest-nat pour ton synology depuis l'interface wireguard ? Tu peux mettre le contenu de cette règle ? Ton dest-nat a déjà été fait sur ton VPS (ie tu as déjà la bonne IP dest sur ta capture en tout cas).