LAN via Routeur 4G et VPN via VPS : Route/NAT/Forward ?
Résoludam1dam1 Messages postés 5 Date d'inscription lundi 23 février 2004 Statut Membre Dernière intervention 6 août 2024 - 6 août 2024 à 11:33
- LAN via Routeur 4G et VPN via VPS : Route/NAT/Forward ?
- Vpn gratuit - Guide
- Vpn comment ça marche - Guide
- Impossible d'envoyer le message via free erreur 0 ✓ - Forum Mobile
- Frequence 4g - Guide
- Torrent sans vpn - Forum Virus
11 réponses
31 juil. 2024 à 14:42
bonjour,
Le VPN est sensé faire croire que les clients sont sur le LAN du serveur.
Si tu veux travailler via VPN, le serveur VPN doit donc se trouver sur LANgcs.
31 juil. 2024 à 14:48
Merci !
Heu, non c'est pas un impératif, je pense.
VPN client to client.
De plus, impossible de mettre le serveur VPN sur le LANgcs:
C'est un Internet 4G !!! Pas d'ip public !!!
31 juil. 2024 à 15:03
Tu dois alors accepter que les clients du VPN n'aient pas une visibilité directe sur les organes du LAN, et utiliser le routeur comme intermédiaire pour les appels vers les organes du LAN.
ClientPC et ServerVPN ne sont pas en local sur LANgcs, ils ont accés exclusivement au routeur. Comme d'ailleurs, tous les ordis connectés à Internet ont accés au routeur.
31 juil. 2024 à 14:56
Avec ta configuration VPN, il est normal que seul le routeur ClientGCS,soit visible depuis serverVPN et PCwin11.
Ce que tu peux faire, c'est configurer le port forwarding du routeur ClientGCS, de façon à ce que ce routeur relaie des appels entrants vers d'autres clients du LAN.
Par exemple, tu peux configurer une redirection de porte de telle façon qu'un appel venant du vpn sur la porte 12345 soit redirigé vers la porte 12345 (ou une autre) de l'adresse 192.168.10.11.
Ainsi, pour se connecter à ton variateur ABB, serverVPN ou PCwin11 feront un appel vers le routeur, et cet appel sera redirigé vers le variateur.
L'utilité du VPN, dans ce contexte, c'est de sécuriser le LAN, car seuls les participants au VPN peuvent "profiter" de la redirection de porte.
31 juil. 2024 à 16:47
Merci bien !
J’apprends toujours !
ok,
Mais, sans règle de forwarding dans le routeur, je ping quand même le PCtest en 222 (si ICMP ‘virtuel’ activé dans son parefeu)
Donc la requête ICMP est bien redirigée par le Routeur… Non ? (Mais ok, c’est pas TCP…)
Et tu dis :
« L'utilité du VPN, dans ce contexte, c'est de sécuriser le LAN ». Oui certes, mais pour moi c’est surtout d’accéder aux organes distants en 4G…
Une autre possibilité ?
BREF :
J’ai fait 2 règles (image. J’hésite entre from VPN ou WAN)
Mais sur mon ClientPC, http://192.168.10.1:3880 ou 10.8.0.2:3880 ne fonctionnent pas. (je ping les 2 adresses)
En local sur le LANgcs (PCtest) ca marche, normal.
Une idée ?
Je suppose que tu va me dire nftable sur le PClinux (en 192.168.10.201)…
Peux-tu me dire, s’il te plait, (et si tu sais) quelle commande exactement ? (Masquarade, Forward… Pfffff, reste à apprendre encore !)
RJ45 du PClinux = enp1s0…
De plus :
Si c’est cela qu’il faut faire, cela sous-entend que je devrais intervenir sur les configs reseau/parefeu de l’automate et du variateur. Je sais même pas si c’est possible…
J’ai une autre vague idée (Rigole pas..) :
Avec ce VPN sur le VPS, j’arrive à atteindre le routeur 4G en ‘IP fixe’ (10.8.0.2 ou 192.168.10.1)
Est-il possible de faire alors un serveur OpenVPN sur le routeur (il a l’option)
Et le clientPC se connecte sur le premier VPN, puis sur le second…
Mais ça fait très farfelu et très bidouille ?
Une autre idée ?
31 juil. 2024 à 19:26
A qui réponds tu yg_be ou moi ?
Mais, c'est quoi que tu appelles icmp virtuel ?
Tu crois qu'il y a un parefeu sur ton automate et ton variateur ? ça me surprendrait.
Mais, sans règle de forwarding dans le routeur, je ping quand même le PCtest en 222 (si ICMP ‘virtuel’ activé dans son parefeu)
je parlais de routage dans le VPS.
Il faudrait éviter de partir dans tous les sens et se limiter aux tests ping dans l'immédiat.
depuis quelle adresse et vers quelle adresse STP
31 juil. 2024 à 20:43
@Brupala
Effectivement, les réponses ne sont pas nommées et semblent mélangées, pardons.
De plus je n'avais pas vu tes réponses (commentaires en fait) du 31/07 16:49 et 19:26
Mes réponses 2 et 4 étaient destinées à yg_be.
Ma réponse 6 est bien pour toi et reste d'actualité !
Elle répond à ta réponse 5 de 17:27
(J'aurais du faire un commentaire)
Merci.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre questionModifié le 31 juil. 2024 à 17:27
Salut,
Je suis développeur, avec de peu de connaissances en réseau (autre métier)
Sur ce que tu nous décris, tu ne vas pas nous faire croire que tu as peu de connaissance, il faut déjà une bonne maitrise pour se lancer dans une architecture aussi complexe.
Très bonne idée ce VPS en relais pour ouvrir les connexions entrantes sur le routeur 4G, sinon c'est impossible, effectivement.
Reste qu'il doit manquer des choses dans ce VPS pour en faire un vrai routeur: déjà vérifier que le routage ipv4 est bien activé, c'est un VPS linux, je suppose ?
Ensuite, il faut des routes statiques car le paramètre openvpn client to client ne suffit pas, il ne permet de communiquer que dans le réseau 10.8.0.0/24, pas avec 192.168.10.0/24
donc déjà une route statique de 192.168.10.0/24 via 10.8.0.2
Dans l' autre sens depuis lan GCS , il suffit que les machines aient la route par défaut vers 192.168.10.1, normalement, le routeur doit se débrouiller derrière, mais ça va être plus compliqué car il faudra renvoyer sur 10.8.0.3 (pc client) aussi, au lieu de 10.8.0.1 la route statique 192.168.192.0/24 via 10.8.0.1 est d'ailleurs fausse, ça doit être 10.8.0.3, mais effectivement elle ne sert probablement à rien, l'adresse source de PC client pour aller sur Lan GCS devant être celle ci en principe une vois le vpn connecté.
Pour moi le problème n'est donc pas sur routeur client 10.8.0.2, mais sur le VPS, du moins son routage.
Pour test, j'ai mis un PCtest sur LANgcs. Après avoir activé ICMP (local) dans le parefeu de PCtest, tous les organes de LANgcs ping bien PCtest, mais ClientPC et serverVPN ne ping pas PCtest. Après avoir activé ICMP (virtuel) dans le parefeu de PCtest, ClientPC et serverVPN ping bien PCtest. mais alors je comprends pas !!
Là moi non plus, ça passe ou ça ne passe pas ?
C'est quoi icmp virtuel ?
je veux faire comme si ClientPC était en local sur LANgcs !!! C'est pas le but d'un VPN !?
Il ne peut pas être en local vu qu'il est derrière un (deux) routeurs (voire beaucoup plus en ajoutant ceux de l'internet.
Rappel ton serveur vpn est distant, et on peut installer un vpn surtout routé pour d'autres buts.
31 juil. 2024 à 19:00
il faut déjà une bonne maitrise pour se lancer dans une architecture aussi complexe.
rès bonne idée ce VPS en relais pour ouvrir les connexions entrantes sur le routeur 4G, sinon c'est impossible, effectivement.
Merci, mais je galère ! Autodidacte et pas de copain calé en Réseau !
déjà vérifier que le routage ipv4 est bien activé, c'est un VPS linux, je suppose ?
Oui, Debian11
routage ipv4 ? c’est ca : ?
sudo nano /etc/sysctl.conf
¤
net.ipv4.ip_forward=1
¤
sudo sysctl -p
Je sais pas comment vérifier que c'est opérationnel !
(ok après reboot !??)
Ensuite, il faut des routes statiques car le paramètre openvpn client to client ne suffit pas, il ne permet de communiquer que dans le réseau 10.8.0.0/24, pas avec 192.168.10.0/24.
donc déjà une route statique de 192.168.10.0/24 via 10.8.0.2
Sur le VPS, j'ai fait:
root@srv566162:/etc/openvpn# ip route add 192.168.10.0/24 via 10.8.0.2
et ca renvoi:
RTNETLINK answers: File exists
Ou c'est pas là ??
Et il faudra relancer qqch je suppose ?
comment vérifier que c'est ok ? et après reboot ??
Dans l' autre sens depuis lan GCS…
...
...
Je n’ai pas tout compris ce paragraphe !
il suffit que les machines aient la route par défaut vers 192.168.10.1 : OK
il faudra renvoyer sur 10.8.0.3… Je fais ça comment où ??
la route statique 192.168.192.0/24 via 10.8.0.1(3)… Je la vire, ok ?
C'est quoi icmp virtuel ?
Lol ! Je sais pas trop ! Sur le parefeu de PCtest, j’ai pleins de lignes sur ICMP :
« Analyse de l’ordinateur virtuel (demande d’echo - Trafic entrant ICMPv4) » (ici, mon « virtuel »)
¤
« Diagnostics de réseau de base – Demande d’écho ICMP (ICMPv4-Entrant) » (ici, mon « local »)
(¤ : J'ai pas trouvé à faire un saut de ligne !!)
Merci pour l'aide !
31 juil. 2024 à 22:37
Je précise pour les ping:
En local sur le LANgcs tous se ping, dans les deux sens...
Depuis l'interface du routeur aussi (diagnostic ping, connectée en http local 192.168.10.1 via PCtest)
LANgcs est donc OK (en local)
Avec ClientGCS connecté à serverVPN :
Depuis le VPS (serverVPN):
ping de 10.8.0.1 OK (lui-même)
ping de 10.8.0.2 OK (le routeur ClientGCS)
ping de 192.168.10.1 OK (le routeur ClientGCS)
ping de 192.168.10.222 OK (PCtest, et si j'active les lignes écho ICMP dan son parefeu)
ping de 192.168.10.autres PAS ok (y compris le PClinux en .201)
Depuis l'interface du routeur (diagnostic ping, connectée en http local 192.168.10.1 via PCtest)
ping de 10.8.0.1 OK
ping de 10.8.0.2 OK (lui-même)
Avec ClientPC/PCwin11 (c'est le même organe) connecté à serverVPN :
Depuis le VPS (serverVPN):
ping de 10.8.0.3 OK (le client ClientPC)
ping de 192.168.192.200 ?? (le client ClientPC, j'ai pas fait l'essai -> demain...)
Depuis le ClientPC:
ping de 10.8.0.1 OK
ping de 10.8.0.2 OK
ping de 10.8.0.3 OK (lui-même)
ping de 192.168.10.1 OK (le routeur ClientGCS)
ping de 192.168.10.222 OK (PCtest, et si j'active les lignes écho ICMP dan son parefeu)
ping de 192.168.10.autres PAS ok (y compris le PClinux en .201)
Depuis l'interface du routeur (diagnostic ping, connectée en http DISTANT 192.168.10.1 via ClientPC)
Idem, ping de tout le LANgcs et 10.8.0 .1,.2,.3
Note:
Dans mon premier message, il y a une petite erreur d'appellation :
...Un client « PCwin11 » nomade, quelque-part sur le NET
...« ClientPC » le client VPN(10.8.0.3) via le soft "OpenVPN Connect"
PCwin11 et ClientPC désigne le même organe...
31 juil. 2024 à 22:41
Décidément, pas doué sur ce forum... :
dam1dam1 c'est moi aussi (Calimoero90), pas le meme PC, lol)
Modifié le 1 août 2024 à 08:17
Donc le clientPC/PCwin11 nomade, connecté à serverVPN, peut bien pinger 192.168.10.222.
Essaie peut-être, dans la même configuration, un tracert vers 192.168.10.201. Il est possible que, comme PCtest avant modif de son firewall, certains ordis ne répondent pas au ping non local.
Il faudrait maintenant tester le ping dans l'autre sens, par exemple de 192.168.10.222 vers le clientPC/PCwin11 nomade, connecté à serverVPN.
1 août 2024 à 09:30
Pour les tracert/traceroute :
-----------------------------------
Avec ClientGCS(10.8.0.2) connecté à serverVPN :
Depuis le VPS (serverVPN 10.8.0.1):
root@srv566162:~# traceroute 192.168.10.1 (routeur clientGCS, ping OK)
traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 60 byte packets
1 192.168.10.1 (192.168.10.1) 45.625 ms 44.906 ms 44.779 ms
root@srv566162:~#
root@srv566162:~# traceroute 192.168.10.222 (PCtest, ping ok)
traceroute to 192.168.10.222 (192.168.10.222), 30 hops max, 60 byte packets
1 10.8.0.2 (10.8.0.2) 82.897 ms 82.818 ms 82.782 ms
2 * * * ... 30 * * * (sans erreur)
root@srv566162:~# traceroute 192.168.10.201 (PClinux, ping PAS ok)
traceroute to 192.168.10.201 (192.168.10.201), 30 hops max, 60 byte packets
1 10.8.0.2 (10.8.0.2) 50.124 ms 64.291 ms 68.329 ms
2 * * * ... 30 * * * (sans erreur)
Avec clientPC (10.8.0.3) connecté à serverVPN :
Depuis le VPS (serverVPN 10.8.0.1):
root@srv566162:~# traceroute 192.168.10.1 (routeur clientGCS, ping OK)
root@srv566162:~# traceroute 192.168.10.222 (PCtest, ping OK)
root@srv566162:~# traceroute 192.168.10.201 (PClinux, ping PAS ok)
Idem (normal)
Depuis le clientPC (192.168.10.201):
PS C:\Users\Damien> tracert 192.168.10.1 (routeur clientGCS, ping OK)
Détermination de l’itinéraire vers 192.168.10.1 avec un maximum de 30 sauts.
1 130 ms 116 ms 116 ms 192.168.10.1
Itinéraire déterminé.
PS C:\Users\Damien> tracert 192.168.10.222
Détermination de l’itinéraire vers 192.168.10.222 avec un maximum de 30 sauts.
1 56 ms 76 ms 76 ms 10.8.0.2 (PCtest, ping OK)
2 85 ms 77 ms 76 ms 192.168.10.222
Itinéraire déterminé.
PS C:\Users\Damien> tracert 192.168.10.201
Détermination de l’itinéraire vers 192.168.10.201 avec un maximum de 30 sauts.
1 81 ms 73 ms 54 ms 10.8.0.2
2 * * * Délai d’attente de la demande dépassé.
... 30 idem
et le ping sur PClinux ne semble pas desactivé:
cat /proc/sys/net/ipv4/icmp_echo_ignore_all
donne 0
pour les ping dans le sens PCtest(192.168.10.222) vers clientPC(192.168.192.200) (C'est pas ce que je veux faire, mais bon) :
(Avec clientPC (10.8.0.3) connecté à serverVPN)
Depuis le PCtest (192.168.10.222):
ping 10.8.0.3 (clientPC) OK
ping 192.168.192.200 (clientPC) PAS ok
tracert 192.168.192.200
Détermination de l’itinéraire vers 192.168.192.200 avec un maximum de 30 sauts.
1 1 ms 1 ms 1 ms 192.168.10.1
2 * * * Délai d’attente de la demande dépassé.
... 30 idem
1 août 2024 à 10:43
Je pensais que clientPC était quelque part sur le net. Maintenant il est sur le LAN en 192.168.192.200? Et parfois en même temps sur le LAN et connecté via le VPN?
Le ping fonctionnant bien dans les deux sens entre 192.168.10.222 et 10.8.0.3, j'essaierais autre chose, par exemple http ou telnet, entre les deux. Si tout va bien, tu devrais avoir une réponse immédiate, plutôt qu'une erreur sur timeout.
1 août 2024 à 19:30
Bien, vous discutez même entre vous et c'est très bien ! Merci !
Je comprends que finalement ce ne serait pas un problème de route ou forwarding dans serverVPN, clientGCS(routeur4G) ou PClinux(.10.201),
mais plutôt un problème de parefeu dans ces organes, principalement dans le PClinux.
(et quid des auttomate et variateur !!... Grrr...Next problem...)
PAREFEU :
voici déjà sur le serverVPN :
root@srv566162:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
34299 7292K ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:44090
192 16056 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
20 1040 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth0 tun0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
root@srv566162:~#
Demain j'essai de faire idem avec le nft(que je ne connais pas encore...) de PClinux
Dans l'intervalle, j'ai pas tout compris:
Vous voulez que je test quoi d'autres au juste ?
Encore merci.
Modifié le 1 août 2024 à 19:52
si tu pouvais tenter du tcpdump icmp sur 10.201 et faire un ping dessus
pas beaucoup de paquets en forward, mais bon, comme c'est entre 2 clients openvpn, la chaine ne doit pas être concernée en dehors de l'établissement des deux connexions vpn.
PS,
oui, je me suis trompé au <27>, je voulais répondre au <24> et j'ai répondu au <26>
1 août 2024 à 20:56
Tu as deux PC qui communiquent correctement entre eux, me semble-t-il:
- clientPC (192.168.192.200, 10.8.0.3),
- PCtest (192.168.10.222)
Chacun peut pinger l'autre.
Il serai utile de tester si il peuvent communiquer par TCP entre eux. Par exemple, via http ou via telnet.
2 août 2024 à 10:28
Bonjour à vous !
1.
Comment interprétez vous ces deux erreurs différentes, est-ce normal ? :
depuis clientPC (192.200) vers PClinux (10.201)
PS C:\Users\Damien> ssh xxx@192.168.10.201
ssh: connect to host 192.168.10.201 port 22: Connection timed out
PS C:\Users\Damien> ssh xxx@10.8.0.2
ssh: connect to host 10.8.0.2 port 22: Connection refused
PS C:\Users\Damien>
2.
De plus, vous me confirmez bien que c'est normal que, une fois clientPC connecté au serverVPN,
je n'ai pas (sur clientPC) une "Carte reseau magique" avec qqch comme:
Carte OpenVPN :
Adresse IPv4. . . . . . . . . . . . . .: 192.168.10.??? (?:srv DHCP ? ou fixée qqpart ?)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : 192.168.10.1
3. ip route depuis le VPS
Et voici sur le VPS (serverVPN):
root@srv566162:~# ip route
default via 82.112.241.254 dev eth0 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
82.112.241.0/24 dev eth0 proto kernel scope link src 82.112.241.69
192.168.10.0/24 via 10.8.0.2 dev tun0
root@srv566162:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 82.112.241.254 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
82.112.241.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
root@srv566162:~#
4.
(@brupala <32>)
j'ai pas tcpdump sur ce Debian, je vais installer et voir ca.
Tu me demande de faire juste :
"# tcpdump icmp"
sur PClinux (10.201) et de lancer un ping depuis clientPC (et serverVPN) vers 10.201 c'est bien ça ?
5.
(@yg_be <33>)
Heu, non, voir ma réponse en <17> du 01/08 à 11:33
(Ou j'ai pas compris)
6.
nft sur clientPC 10.201, pas encore fait
7.
là, je suis ocupé à installer un clientVPN sur le PC de l'automaticien pour voir s'il peu se connecter, par magie(?), à l'automate (10.10 ou 10.20)
(La vraie finalité en fait)
8.
Si .7 ne marche pas... J'ai très peur...
Avec cette config, le VPN ne simule pas une connection local de clientPC sur le reseau LANgcs,
ce qui amène ces problemes...
y a t-il qqch à faire de mieux ?
Est-rentable que je passe du temps à mon idée "farfelue" du début <5>:
Avec ce VPN sur le VPS, j’arrive à atteindre le routeur 4G en ‘IP fixe’ (10.8.0.2 ou 192.168.10.1)
Est-il possible de faire alors un serveur OpenVPN sur le routeur (il a l’option)
Et le clientPC se connecte sur le premier VPN, puis sur le second…
Mais ça fait très farfelu et très bidouille..
Modifié le 2 août 2024 à 11:26
1.
ces deux erreurs différentes,
depuis clientPC (192.168.10.200)
-)vers 192.168.10.201, 192.168.10.201 ne reçoit pas a demande de connexion, ou la réponse est perdue (?firewall?)
-) vers 10.8.0.2, le routeur refuse cette connexion, la communication fonctionne bien
.
.
2. ce n'est pas nécessaire, car clientPC (192.168.192.200 et 10.8.0.3) a bien une route vers 192.168.10.0/24, avec 10.8.0.1 comme passerelle.
Cela me semblerait absurdement complexe que le logiciel VPN crée ainsi un "interface virtuel" dans cette situation.
Modifié le 2 août 2024 à 17:09
Salut, on reprend, donc,
1.
j'ai lu la réponse de Yg_be en <35> et je suis d'accord avec lui, par contre un parefeu peut renvoyer une réponse icmp, genre port unreachable, je ne sais pas vraiment comment c'est interprété par SSH, en tout cas, ça ne devrait pas être time out.
2.
pareil, la carte réseau magique n'existe pas dans ce cas, la seule connexion réseau valable pour ça c'est 10.8.0.3. une carte réseau ne peut exister que vers un réseau directement connecté, physique ou virtuel.
3.
Tout a l'air normal à ce niveau.
4.
voui, c'est ça tout à fait, on se comprend bien :-)
5.
...
6.
...
7.
...
8.
Double couche vpn ... c'est toujours des soucis, déjà en MTU, ou MSS plutôt, 40 octets en moins sur un openvpn tcp , mais ça peut être pratique et ça se fait de plus en plus, mais vu qu'on est plus sur un problème de parefeu terminal, ça ne résoudrait rien, il faut vraiment une meilleure évaluation des matériels au bout sur GCS à moins que le routeur soit vraiment tordu au niveau parefeu .
2 août 2024 à 17:33
En général, les parefeux sont muets, ils causent simplement des pertes de paquet. Ce qui conduit à des sessions qui restent en SYN SENT, jusqu'à timeout.
2 août 2024 à 18:40
C'est vrai c'est comme ça qu'ils sont le plus efficaces, mais fail2ban par exemple, qui n'est pas vraiment un parefeu, d'accord, par défaut renvoie port unreachable (ça peut être juste drop aussi)
Modifié le 2 août 2024 à 11:38
Tu as deux PC qui communiquent correctement entre eux, me semble-t-il:
- clientPC (192.168.192.200, 10.8.0.3),
- PCtest (192.168.10.222)
Peux-tu confirmer que chacun peut pinger l'autre :
10.8.0.3 <====> 192.168.10.222
Il serai utile de tester si il peuvent communiquer par TCP entre eux. Par exemple, via http ou via telnet ou ssh.
Le but étant de vérifier si la connexion est acceptée, refusée, ou si elle expire en timeout.
Une connexion acceptée ou refusée indique que la communication fonctionne bien dans les deux sens.
5 août 2024 à 12:51
Bonjour,
Me revoila avec toujours mon problème...
@yg_be<36>:
Oui, les deux ping dans les deux sens.
ce sont deux windows11, sans serveur http ni ssh ni telnet...
Pour faire du TCP, je pourais installer un petit qqch si vraiment il faut,
mais déjà ca ne cause meme pas bien sur le VPS (serverVPN)
@tous:
Bon, lorsque j'ai voulu installer tcpdump sur le PClinux (10.201),
je me suis appercu que le gateway de enp1s0 etait en fait le gw du enp3s0
(qui ne sert pas pour l'instant. problème de config)
c'est réglé, j'ai bien gw=192.168.10.1 (le routeur) maintenant.
Du coup, ping 192.168.10.201 passe bien depuis le severVPN et depuis le clientPC
(lan externe 192.168.192.200 => maintenant chez moi, c'est 192.168.1.85)
(Et le tcpdump icmp sur le PClinux donne bien request et reply echo)
MAIS depuis serverVPN (et depuis le clientPC), le wget du PClinux (10.201) ne fonctionne pas.
(Ca marche en local)
root@srv566162:~# wget http://192.168.10.201:3880
--2024-08-05 09:22:45-- http://192.168.10.201:3880/
Connecting to 192.168.10.201:3880... ^C
J'ai lancé un tcpdump (tout court, donc tout le trafic)
et ca ne donne rien
(que la repetition infinie de deux lines sur le ssh en cours (local) je suppose)
Je precise que le nft sur le PClinux est:
#sudo service nftables status
...disable, inactive, dead...
Ci-dessous, quelques règles que j'ai essayé dans le routeur...
Idem...
GRrrrr.. !
Des idées ?
Merci !
5 août 2024 à 13:25
Salut,
il y a du ssh dans windows 11 (openssh)
On n'avait jamais parlé que tu avais plusieurs ethernet sur ton pc linux
Vérifie que ton serveur http n'est pas configuré que pour écouter sur localhost, il faut lui dire d'écouter ton lan pour ce wget.
Pour le tcpdump, si tu accèdes en ssh, bien sûr il faut filtrer pour ne pas capturer en miroir infini le traffic ssh
tcpdump port 3380 ou tcpdump -i enp1s0 port 3380
Modifié le 5 août 2024 à 14:11
Sur un des deux PC, tu fais ceci dans une fenêtre PowerShell:
$Listener = [System.Net.Sockets.TcpListener]9999; $Listener.Start(); $client = $Listener.AcceptTcpClient();
Sur l'autre PC, tu fais ceci dans une fenêtre PowerShell:
Test-NetConnection -ComputerName 1.2.3.4 -port 9999
en remplaçant 1.2.3.4 par l'adresse IP du premier PC.
Cela te permet de vérifier que le routage fonctionne bien entre les deux PC.
5 août 2024 à 16:02
Bon,
Je suis un gros con...
Je confirme,
Depuis que j'ai mis la bonne passerelle dans mon /etc/network/interfaces,
ça marche beaucoup mieux!
J'ai viré toutes les règles dans le routeur4G, j'ai redémarré le routeur, le VPS, le PClinux, le clientVPN du clientPC
Et ça marche !! (Tout cause, ping, tracert, http...)
Depuis clientPC, j'arrive même à me connecter avec winSCP et aussi à mon dev via studio code en remote (ssh)
et même en réactivant le parefeu nft du PClinux (bon, une bonne passoire pour l'instant... à voir)
En fait, mon PClinux est un mini PC industriel avec 3 RJ45 dont une seule est utilisé (enp1s0).
enp3S0 etait configuré pour un autre cas (non branchée)
Mais apparemment, c'est seulement la dernière ligne gateway qui est prise en compte dans ce fichier
(Ou j'ai pas encore tout compris !!!, à voir)
Bref, je suis vraiment désolé de vous avoir fait perdre votre temps.
Mais j'ai beaucoup appris avec votre aide, merci !
En conclusion,
Il faut quand même activer le ICMP distants sur les PC windows11 (normal, on n’est pas en local, non non !)
item : Ordinateur virtuel - ICMP echo - Trafic entrant IPv4. (virtuel veut dire ici distant je suppose, pas direct en tout cas!)
Pour les automates, j'ai un peu vu des tutos qui montrent que l'on peut activer un mode "connexion à distance",
J’ai donc bon espoir ! A voir (Je suis pas au boulot là, mais en vacance. Si si !)
Pour les variateurs, je sais pas... J'espère aussi !
MERCI TOUT PLEIN A VOUS DEUX !
En cas de gros problème, je reviens sur ce forum !!!
5 août 2024 à 17:43
Arf,
au contraire, tu as très bien su analyser ton problème, avec un poil d'aide :-)
je vais juste préciser une chose que tu ne sembles pas avoir bien maitrisé encore:
une passerelle par défaut, route par défaut en fait, c'est forcément unique, car la seule qui reste, pour une fois le nom colle bien, quand toutes les autres ne vont pas, comme tu programmes, ça correspond à la fin d'un switch/case ou un il/else bien bouclé.
C'est vrai que toutes les configurations ip d'interface proposent une passerelle en complément, mais une seule sera utilisée.
Content que tu arrives au bout et dommage que cette petite erreur t'ait fait perdre du temps, en même temps tu l'auras passé à apprendre des choses qui te serviront à d'autres occasions :-)
Bonnes vacances, passe la discussion en résolu, STP.
5 août 2024 à 20:24
Je me demande où tu vois
"item : Ordinateur virtuel - ICMP echo - Trafic entrant IPv4".
Le parefeu de Windows permet de contrôler ICMP echo,
- en émission ou en réception
- suivant que le correspondant soit local (sous-réseau) ou distant
- suivant qu'on soit dans un domaine, un réseau "privé", ou un réseau "public"
Par contre, je ne vois pas où "ordi virtuel" intervient dans le parfeu.
5 août 2024 à 20:58
6 août 2024 à 11:31
"core networking disgnostics" en anglais.
"analyse de l'ordinateur virtuel" en français.
6 août 2024 à 11:33
LOL ! Ces traducs !
31 juil. 2024 à 16:49
Salut,
justement le serveur vpn doit servir à permettre les connexions entrantes sur le routeur 4G via le VPN, sinon accès impossible cause que réseau mobile ça n'est pas internet.