La Fibre
Datacenter et équipements réseaux => Routeurs => 
MikroTik RouterOS => Discussion démarrée par: Asclèpios le 28 avril 2023 à 16:01:26
-
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/ (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 ?
-
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.
-
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 ?"
-
Bon finalement en regardant plus précisément, niveau route je pense que tu es pas trop mal.
Une capture permettrait d'y voir plus clair avec https://wiki.mikrotik.com/wiki/Manual:Tools/Packet_Sniffer (https://wiki.mikrotik.com/wiki/Manual:Tools/Packet_Sniffer)
En cli, je ferai un /tool/sniffer
Puis je paramètrerai l'interface wg : edit interface, puis tu mets ton interface wg
tu lances la capture avec "quick" puis tu fais ton test.
Si tout est ok côté "site central", tu devrais voir un syn et le syn ack qui repart dans ton interface wg.
Si on voit ça le problème serait côté VPS (peut être les règles de redirections ou autre), si on voit pas ça surement du routage sur le site central.
-
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 ?
-
Bonjour,
Il me semble qu'il est nécessaire d'autoriser l'ip forward et de faire du masquerading sur le VPS pour que ça fonctionne.
Je ne crois pas avoir vu ça dans le premier post.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADESi eth0 est l'interface portant l'IP publique.
edit : ajout de la règle iptables
-
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 )
-
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 )
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 :
Les IP en 37.** correspondent à quoi alors ? C'est bien un équipement à toi ?
J'ai bien essayé un sniff de l'interface wireguard mais tout reste vide (pas de racket ) :
Sur le VPS ou mikrotik ?
-
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
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).
-
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 :
Les IP en 37.** correspondent à quoi alors ? C'est bien un équipement à toi ?
J'ai bien essayé un sniff de l'interface wireguard mais tout reste vide (pas de racket ) :
Sur le VPS ou mikrotik ?
Je n'ai pas de certitude si ce n'est que cette ip m'est inconnu.
Le sniff depuis le mikrotik
-
Peux tu nous afficher les règles 7 et 8 de NAT de ton routeur ?
Je comprends pas trop à quoi elles servent.
-
Le SYN est envoyé mais pas de retour de ton Mikrotik.
Tu as un problème de routage côté Mikrotik.
Merci on progresse doucement mais grandement grâce a toi ... Que faut-il faire ? Peut-être qu'un te partager un acces a mon routeur pourrai m'aider ?
-
Je n'ai pas de certitude si ce n'est que cette ip m'est inconnu.
Le sniff depuis le mikrotik
Sur ta capture, tu as bien cliqué sur "start" ?
-
Peux tu nous afficher les règles 7 et 8 de NAT de ton routeur ?
Je comprends pas trop à quoi elles servent.
Elle me permettent d'accéder a mes nom de domaine locaux depuis mon domicile
Ex : Depuis mon tel si je veux accéder a homeassistant.monnomdomaine.fr en wifi
cf : https://help.mikrotik.com/docs/display/ROS/NAT#NAT-HairpinNAT
-
Sur ta capture, tu as bien cliqué sur "start" ?
Oui en effet
-
Sur ton poste de 12h58 tu as 2 règles de NAT avec In.Interface wireguard, qui ne correspondent pas aux derniers screenshot. Ces règles existent toujours ?
-
Du coup c'est les règles 3-4, tu peux les afficher ?
-
Du coup c'est les règles 3-4, tu peux les afficher ?
Les voici :)
-
Les voici :)
Pourquoi tu as fait ça ? ;D
Supprime et ça marchera je pense
-
Tu peux refaire un sniffer sans ces règles sur l'interface wireguard ?
Il y a toujours rien ?
-
J'avais pas vu, tu peux afficher la règle 1 aussi, la règle 8 et la règle 12.
Normalement tu n'as pas à faire de NAT pour le wireguard.
-
Tu peux refaire un sniffer sans ces règles sur l'interface wireguard ?
Il y a toujours rien ?
Toujours rien mais par curiosité j'ai essaye avec all et absolument rien non plus ! what ?
-
Toujours rien mais par curiosité j'ai essaye avec all et absolument rien non plus ! what ?
Bizarre oui, tu as quoi dans l'onglet Général de ton packet sniffer.
-
J'avais pas vu, tu peux afficher la règle 1 aussi, la règle 8 et la règle 12.
Normalement tu n'as pas à faire de NAT pour le wireguard.
Regle 1
Regle 8 : Prevu pour plus tard
-
Regle 1
Celle là aussi tu peux la supprimer.
En gros toutes les règles avec l'interface wireguard pour moi il faut enlever ou alors m'expliquer à quoi elles servent.
-
Voici mon firewall mis a jour
Voila ça ma parait bien mieux déjà.
Avec ça, c'est toujours pas fonctionnel je suppose ?
Il faudrait voir pourquoi ton packet sniffer affiche rien, surtout si tu mets interface all. Tu pourrais afficher l'onglet general ?
-
Voila ça ma parait bien mieux déjà.
Avec ça, c'est toujours pas fonctionnel je suppose ?
Il faudrait voir pourquoi ton packet sniffer affiche rien, surtout si tu mets interface all. Tu pourrais afficher l'onglet general ?
Voila l'onguet général
-
Mais toujours rien
-
Ok étrange, tout à l'air bien. Dans l'onglet filter, il y a rien de set plus bas ? vu qu'il y a l'ascensseur.
Tu fais bien apply puis start et tu clique sur packet ?
Si tu mets interface all tu devrais avoir des trucs quand même.
-
Ok étrange, tout à l'air bien. Dans l'onglet filter, il y a rien de set plus bas ? vu qu'il y a l'ascensseur.
Tu fais bien apply puis start et tu clique sur packet ?
Si tu mets interface all tu devrais avoir des trucs quand même.
Oui c'est clair mais peut être un bug avec la Router OS 7.9 rc3
A tout hasard j'ai tenté un reboot du routeur ... On va voir
-
Si le packet capture du Mikrotik marche pas, peux tu au moins faire un tcpdump sur le synology ? Quelque chose comme ça (pour du https par exemple) et tester :
tcpdump -ni *lenomdetoninterface* tcp port 443
Ca permettrait de vérifier que ton serveur reçoit une requête et qu'il répond bien. Si on a ça c'est vraiment au niveau du routeur qu'on a quelque chose qui va pas. Peux-tu aussi remettre la table de routage du routeur actualisé (normalement elle a pas changée ?)
-
Si le packet capture du Mikrotik marche pas, peux tu au moins faire un tcpdump sur le synology ? Quelque chose comme ça (pour du https par exemple) et tester :
tcpdump -ni *lenomdetoninterface* tcp port 443
Ca permettrait de vérifier que ton serveur reçoit une requête et qu'il répond bien. Si on a ça c'est vraiment au niveau du routeur qu'on a quelque chose qui va pas. Peux-tu aussi remettre la table de routage du routeur actualisé (normalement elle a pas changée ?)
Pour info tcpdump cote vps
SUPPRIMER POUR CONFIDENTIALITE
Et ci-joint route avec fibre active et fibre désactive via br-wan. le tcp depuis Synology arrive
-
Oui côté VPS ça a pas changé.
On dirait vraiment qu'il route mal le paquet de retour.
Edit : Il faudrait passer la route de la fibre à une distance de 5 pour être sur ou la supprimer. De plus, contrairement au début tes deux routes on la même distance maintenant, ça ne va pas.
En gros supprime toutes les routes 0.0.0.0 et garde que la route par defaut 0.0.0.0 vers l'Ip du wireguard distant (VPS)
-
Si le packet capture du Mikrotik marche pas, peux tu au moins faire un tcpdump sur le synology ? Quelque chose comme ça (pour du https par exemple) et tester :
tcpdump -ni *lenomdetoninterface* tcp port 443
Ca permettrait de vérifier que ton serveur reçoit une requête et qu'il répond bien. Si on a ça c'est vraiment au niveau du routeur qu'on a quelque chose qui va pas. Peux-tu aussi remettre la table de routage du routeur actualisé (normalement elle a pas changée ?)
Et voila le tcpdump
Supprimer
-
Et voila le tcpdump
Ca confirme bien que le serveur reçoit bien et renvoit correctement.
C'est ce qu'on souspçonne depuis le début, à savoir un problème de routage au niveau du routeur.
Personnellement, je ferai du ménage dans les routes.
Quand ta fibre est down, tu devrais avoir qu'une seule route 0.0.0.0 et elle devrait pointer sur l'IP wireguard du VPS.
-
Ca confirme bien que le serveur reçoit bien et renvoit correctement.
C'est ce qu'on souspçonne depuis le début, à savoir un problème de routage au niveau du routeur.
Personnellement, je ferai du ménage dans les routes.
Quand ta fibre est down, tu devrais avoir qu'une seule route 0.0.0.0 et elle devrait pointer sur l'IP wireguard du VPS.
Que devrais-je faire d'après toi coté route ?
-
Que devrais-je faire d'après toi coté route ?
Supprime toutes les routes en 0.0.0.0/0 et mets juste cette route :
0.0.0.0/0 -> 192.168.100.100
Edit :
+ une route statique vers l'ip publique de ton VPS :
Ip publique du VPS -> WAN orange (10.48 quelque chose ?)
-
Supprime toutes les routes en 0.0.0.0/0 et mets juste cette route :
0.0.0.0/0 -> 192.168.100.100
Edit :
+ une route statique vers l'ip publique de ton VPS :
Ip publique du VPS -> WAN orange (10.48 quelque chose ?)
J'ai laissé uniquement cette seule route active et j'ai supprimé la route 4G mais évidemment, cela m'a coupé la connexion internet
-
AS tu ajouté cette route aussi :
Ip publique du VPS -> WAN orange (10.48 quelque chose ?)
-
AS tu ajouté cette route aussi :
Ip publique du VPS -> WAN orange (10.48 quelque chose ?)
Non pourquoi ?
-
Non pourquoi ?
Vu qu'on a enlevé la route par defaut il faut que ton routeur puisse tout même joindre ton serveur VPS pour pouvoir monter le wireguard.
-
Vu qu'on a enlevé la route par defaut il faut que ton routeur puisse tout même joindre ton serveur VPS pour pouvoir monter le wireguard.
La route 4G par default s'est recréer automatiquement
-
AS tu ajouté cette route aussi :
Ip publique du VPS -> WAN orange (10.48 quelque chose ?)
Donc si je comprends bien
0.0.0.0/0 --> 192.168.100.100
IP Pub VPS ---> Wan Orange
-
La route 4G par default s'est recréer automatiquement
Dans ce cas là, il faut :
Une route par defaut : 0.0.0.0/0 -> 192.168.100.100 : distance 1
Une route statique vers l'IP publique du VPS via le WAN 4G : Ip pub VPS -> Wan orange 4G
Modifier la route 4G par défaut pour qu'elle ait au moins une distance supérieur à la route 1 si tu peux pas l'enlever et qu'elle revient d'elle même. Par exemple mettre une distance à 5.
Avec ça tu devrais être bon. Car là ce qu'il se passe c'est que ton flux retour passe surement dans la route par défaut 4G au lieu de prendre ton tunnel wireguard.
-
Dans ce cas là, il faut :
Une route par defaut : 0.0.0.0/0 -> 192.168.100.100 : distance 1
Une route statique vers l'IP publique du VPS via le WAN 4G : Ip pub VPS -> Wan orange 4G
Modifier la route 4G par défaut pour qu'elle ait au moins une distance supérieur à la route 1 si tu peux pas l'enlever et qu'elle revient d'elle même. Par exemple mettre une distance à 5.
Avec ça tu devrais être bon. Car là ce qu'il se passe c'est que ton flux retour passe surement dans la route par défaut 4G au lieu de prendre ton tunnel wireguard.
J'ai désactive l'option route par default pour l'interface 4G Est-ce bon ?
-
Si on récap :
Une route par defaut : 0.0.0.0/0 -> 192.168.100.100 : distance 1 :
Tu as mis la route en distance 2 mais c'est pas très grave si tu as réussi à enlever la route par défaut 4G
Une route statique vers l'IP publique du VPS via le WAN 4G : Ip pub VPS -> Wan orange 4G
Je suppose que c'est la dernière ligne, si les Ip sont bonne alors c'est bon (l'IP 10.254.178.1 est l'Ip de la "box" 4G ?)
Modifier la route 4G par défaut pour qu'elle ait au moins une distance supérieur à la route 1 si tu peux pas l'enlever et qu'elle revient d'elle même. Par exemple mettre une distance à 5.
Tu as réussi à la supprimer donc c'est bon.
Donc avec ça si t'éteins la fibre je dirais que tu es pas mal.
-
Si on récap :
Une route par defaut : 0.0.0.0/0 -> 192.168.100.100 : distance 1 :
Tu as mis la route en distance 2 mais c'est pas très grave si tu as réussi à enlever la route par défaut 4G
Une route statique vers l'IP publique du VPS via le WAN 4G : Ip pub VPS -> Wan orange 4G
Je suppose que c'est la dernière ligne, si les Ip sont bonne alors c'est bon (l'IP 10.254.178.1 est l'Ip de la "box" 4G ?)
Modifier la route 4G par défaut pour qu'elle ait au moins une distance supérieur à la route 1 si tu peux pas l'enlever et qu'elle revient d'elle même. Par exemple mettre une distance à 5.
Tu as réussi à la supprimer donc c'est bon.
Donc avec ça si t'éteins la fibre je dirais que tu es pas mal.
Toujours pas dans ce cas la, sa ne fonctionne plus (pas d'internet)
-
Toujours pas dans ce cas la, sa ne fonctionne plus (pas d'internet)
C'est bizarre car tu as toujours les route en 90.**.
Tu peux les désactiver ou les passer en distance supérieure comme 5 ? Je pense que vu que tu utilises un bridge ces routes là ne passent pas down.
Vu que tu n'as plus internet, je suppose que tu peux pas faire de tcpdump sur le serveur VPS.
-
C'est bon j'ai réussi ... Mais la bonne solution était entre les route et les mangle :) Je fait un tuto demain ou dans quelques heures. En tout cas merci a toi tu ma aider a réfléchir et ta patience ma donné la force de trouvé la solution
-
C'est bon j'ai réussi ... Mais la bonne solution était entre les route et les mangle :) Je fait un tuto demain ou dans quelques heures. En tout cas merci a toi tu ma aider a réfléchir et ta patience ma donné la force de trouvé la solution
Très bonne nouvelle :D
-
Très bonne nouvelle :D
Oui c'est clair et puis je penses que cela sera utile à beaucoup d'entre nous par ici, en tout cas merci de ta présence et de ton soutiens tout au long de cette après-midi les piste que tu m'as donné mon donné l'énergie de trouvé la solution apres 7j de recherche. Un grand merci a toi.
Pourras-tu retirer les tcpdump en citation (pour éviter de laisser trainer les adressages