Ça aurait été plus utile de montrer la table de routage avec la connexion au VPN.
Ce n’est pas avec des règles de firewall qu’on fait du routage, mais avec des routes et si nécessaire des règles de routage avancé. Les règles de firewall interviennent seulement le cas échéant pour manipuler les clés utilisées par les règles de routage (adresse source ou destination, marque de firewall…).
Voilà, sur internet, c’est tout ce que je voulais savoir. Donc toutes les destinations hors du réseau local.
Choisir un numéro de table de routage avancé libre X. Les numéros des tables réservées (local, main, default) sont dans le fichier /etc/iproute2/rt_tables.
Sur PC1, créer deux routes dans cette table :
une route par défaut via PC2
une route directe pour le préfixe du réseau de PC2, identique à celle de la table main pour ne pas envoyer vers PC2 les paquets destinés à d’autres machines de ce réseau.
ip route add default via 192.168.1.2 table X
ip route add 192.168.1.0/24 dev eth1 table X
Si tu veux router tout le trafic de PC3 par le VPN, il suffit d’ajouter une règle de routage avancé basée sur l’adresse source :
ip rule add from 192.168.2.3 table X
Si tu veux router seulement les connexions HTTP(S) et DNS, il faut plutôt marquer les paquets avec iptables (à ajuster si nftables) et créer une règle de routage basée sur la marque de firewall :
iptables -t mangle -A PREROUTING -s 192.168.2.3 ! -d 192.168.1.0/24 -p tcp --dport 80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -s 192.168.2.3 ! -d 192.168.1.0/24 -p tcp --dport 443 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -s 192.168.2.3 ! -d 192.168.1.0/24 -p udp --dport 53 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -s 192.168.2.3 ! -d 192.168.1.0/24 -p tcp --dport 53 -j MARK --set-mark 1
ip rule add fwmark 1 table X
Attention à l’éventuel réglage de rp_filter sur PC1 pour ne pas bloquer les paquets dans le sens retour provenant d’internet de PC2 vers PC3.
En gros, il faut que la passerelle par defaut de PC3 soit l’ip de l’interface PC2 à laquelle il est connecté (directement, via, switch, hub…).
Ensuite PC2 doit forwarder les paquets vers sa passerelle. Il faut donc activer l’ip_forward.
Zargos : PC3 est en wifi sur le réseau 2.0. PC1 et PC2 sont connectés par cable Eth à un switch sur le réseau 192.168.1.0
PascalHambourg : j’ai essayé les manips mais cela n’a pas fonctionné. Je refais proprement et récupérerai les logs. Je redemarre PC1 qui tourne depuis au moins 2 mois.
(sur PC1)ip rule show
0: from all lookup local
32765: from 192.168.2.3 lookup 100
32766: from all lookup main
32767: from all lookup default
…
Le firewall (donc PC1) rejette les packets en provenance de PC3. Il ne faut pas un dnat ?
Souci : PC2 et PC3 ne sont pas connectés directement. Ils sont séparés par PC1.
A moins de monter un tunnel entre PC2 et PC3, il faut faire du routage avancé sur PC1.
Cette phrase ne contient aucune information utile.
Et le contenu de la table de routage 100 ?
ip route ls table 100
Non. Faut arrêter de mettre du NAT partout à tort et à travers. Par contre s’il y a du filtrage il faut peut-être ajuster les règles pour accepter le trafic concerné.
ip route ls table 100
default via 192.168.1.2 dev eth1
192.168.1.0/24 dev eth1 scope link .
Les packets sont rejetés par le firewall
Shorewall:wifi2loc:REJECT:IN=wlp3s0 OUT=eth1 MAC=… SRC=192.168.2.3 DST=x.x.x.x LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=20815 DF PROTO=TCP SPT=36932 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0.
ici DST=x.x.x.x concerne une adresse public chez le fournisseur d’accès VPN.
Ah, shorewall. Je ne pratique pas, j’utilise directement iptables. Tu dois lui dire d’accepter le trafic depuis PC1 par l’interface wifi vers eth1 et vice versa. Si tu veux tester vite fait, tu ajoutes ceci :
iptables -I FORWARD -i wlp3s0 -o eth1 -s 192.168.2.3 -m state --state NEW,ETABLISHED,RELATED -j ACCEPT
iptables v1.8.2 (nf_tables): Bad state « ETABLISHED,RELATED »
J’ai lancé cette même commande en supprimant « ETABLISHED,RELATED » , syslog ne log plus les REJECT, mais l’appli ou le navigateur ne parviennent pas à se connecter à un site inernet (Unable to connect)
faute de frappe de ma part, c’est ESTABLISHED.
Avec seulement l’état NEW, tu ne risques pas de recevoir des réponses.
Question : est-ce que l’équipement/réseau à l’autre bout du VPN sait router correctement l’adresse IP de PC3 ? Sinon il faut faire du SNAT ou MASQUERADE sur l’interface VPN de PC2.
Je n’ai pas vu qu’il manquait le S. Les commandes se sont bien excécutées mais cela n’a pas résolu le problème.
Je ne sais pas si l’équipement/réseau à l’autre bout du VPN sait router correctement l’adresse IP de PC3. Comment faire du source nat sur l’interface VPN du PC2 (tun0)?
Faut-il vérifier avec tcpdump si les paquets arrivent sur certaines interfaces ?