Le routage basé sur le domaine de destination n'est pas impossible et, avec les bons outils, ce n'est pas si difficile.
Je vais présenter quelques méthodes qui nécessitent peu ou pas de configuration spéciale côté client. Tout cela suppose que vous utilisez OpenVPN pour vous connecter. Cela devrait être réalisable avec d'autres VPN, mais peut nécessiter plus de configuration manuelle après la mise en place du VPN.
À titre d'exemple, j'utiliserai les domaines "example.com", "us1.example.com", "us2.example.com" et "geoblocked.com" pour les domaines que nous voulons acheminer via le non-VPN interface.
Toutes les commandes doivent être exécutées en tant que root.
Méthode 1 - OpenVPN
Je ne le recommanderais que si vous êtes certain que les adresses IP que vous routez ont des adresses IP statiques qui ne changent jamais.
Avantages :
- Extrêmement simple
Inconvénients :
- Fiable uniquement pour les domaines avec des adresses IP qui jamais changer
- Besoin d'une entrée explicite pour chaque domaine et sous-domaine
Méthode :
Ajoutez les lignes suivantes à votre configuration OpenVPN :
route example.com 255.255.255.255 net_gateway
route us1.example.com 255.255.255.255 net_gateway
route us2.example.com 255.255.255.255 net_gateway
route geoblocked.com 255.255.255.255 net_gateway
Redémarrez OpenVPN.
C'est tout, mais vous devrez redémarrer le VPN si ces adresses IP changent.
REMARQUE :Certaines sources indiquent que vous devez également spécifier allow-pull-fqdn , mais cela ne semble pas être le cas dans mon expérience. YMMV.
Méthode 2 - Routage basé sur des règles
Le routage basé sur des règles est la capacité de router en fonction de certains critères ; généralement une adresse ou un protocole source, mais dans ce cas, nous inspecterons le nom de domaine de destination avant le routage et utiliserons des paquets marqués ("fwmark").
Donc, ce que nous devons faire en premier est de créer une table séparée pour vos paquets routés VPN, afin que nous puissions marquer ceux qui passent par le VPN, et transmettre les paquets marqués via l'interface non-VPN. (Gardez à l'esprit qu'il s'agit d'une approche et qu'il existe de nombreuses autres façons de l'aborder, comme laisser le VPN effectuer son routage normalement via la table principale et créer une table distincte pour le trafic non VPN.)
Votre noyau doit être assez récent et avoir les modules appropriés, bien que les systèmes modernes les aient probablement dans leurs noyaux par défaut.
Le nom "vpn_table" (le nom de la table de routage) et les nombres "201" (ID de la table de routage) et "3" (fwmark) sont choisis arbitrairement.
Créez la nouvelle table de routage (en tant que root) :
echo 201 vpn_table >> /etc/iproute2/rt_tables
Configurez OpenVPN :
Créez quelque part le script suivant (je l'appelle "/etc/openvpn/client/setup-routing") et rendez-le exécutable :
#!/bin/bash
ip route add 0.0.0.0/1 via $route_vpn_gateway dev $dev scope global table vpn_table
ip route add 128.0.0.0/1 via $route_vpn_gateway dev $dev scope global table vpn_table
sysctl -w net.ipv4.conf.$dev.rp_filter=2
# You can optionally leave the next two lines out but run the `ip rule add`
# command at each boot instead
ip rule del fwmark 3 table vpn_table &>/dev/null # This might fail but that's ok
ip rule add fwmark 3 table vpn_table
Les variables du script ci-dessus seront renseignées en tant que variables d'environnement par OpenVPN. Notez également que cela configure le routage vers tous adresses via la passerelle VPN dans la table de routage "vpn_table". Si votre configuration VPN nécessite un routage plus complexe, reportez-vous à la documentation OpenVPN et ajustez-la en conséquence.
Ajoutez ce qui suit à votre configuration OpenVPN :
## Policy routing
route-noexec
script-security 2
route-up /etc/openvpn/client/setup-routing
La ligne "route-noexec" permet à OpenVPN de récupérer la route du serveur, mais l'empêche de remplir réellement les routes. Au lieu de cela, le script de routage est appelé. "script-security 2" est nécessaire pour appeler un script défini par l'utilisateur.
C'est tout ce qui est nécessaire pour acheminer les paquets marqués, mais nous devons mettre en place un moyen de marquer réellement les paquets. Deux options utilisent dnsmasq avec ipset ou configurent un proxy squid.
Méthode 2a - Routage basé sur des règles utilisant ipset et dnsmasq
Je recommanderais cette méthode si vous l'exécutez déjà sur un routeur basé sur dnsmasq ou si vos clients ne prennent pas en charge la configuration du proxy. C'est effectivement la même chose qu'un DNS de mise en cache qui met à jour la table de routage chaque fois qu'un nom de domaine est recherché.
Avantages :
- Gère les sous-domaines
- Fonctionne sur les appareils qui ne peuvent pas accéder aux proxys (existent-ils ?)
Inconvénients :
- Ne gère pas le champ de référence (voir méthode 2b)
- Nécessite des configurations ipset et iptables compliquées
- Nécessite que le système connecté au VPN soit configuré en tant que routeur (nécessite une interface dédiée)
- Je n'ai aucune idée de l'évolutivité d'ipset (mon cas d'utilisation concerne un ccTLD entier)
Cela suppose que vous avez déjà configuré et configuré dnsmasq, et agissant en tant que passerelle et serveur DNS pour les clients connectés à une interface dédiée "eth1".
Créez l'ipset :
ipset create SKIP_VPN_IPSET iphash
Dites à iptables de marquer les paquets ipset (n.b., cela doit être fait après création de la liste d'ipset) :
# Mark ALL packets coming in on eth1 - change this to the interface dnsmasq listens on
iptables -A PREROUTING -i eth1 -t mangle -j MARK --set-mark 3
# REMOVE mark on any addresses that match our ipset
iptables -A PREROUTING -t mangle -m set --match-set SKIP_VPN_IPSET dst -j MARK --set-mark 0/3
REMARQUE :Les commandes ci-dessus (ipset et iptables ) doit être exécuté à chaque démarrage. Alternativement, votre système d'exploitation peut fournir des options pour enregistrer/restaurer les règles iptable et les ipsets.
REMARQUE2 :Il est documenté un ! --match-set inverse mais cela a entraîné la disparition de tous les paquets lorsque j'ai essayé.
Ajoutez ce qui suit à votre dnsmasq.conf :
ipset=/example.com/geoblocked.com/SKIP_VPN_IPSET
Évidemment, ajustez également cette ligne selon les noms de domaine que vous souhaitez acheminer. Cela ajoutera également TOUS sous-domaines à l'ipset, vous n'avez donc pas besoin de les spécifier explicitement. Même l'utilisation d'un TLD fonctionnera.
Redémarrez dnsmasq et configurez vos clients pour qu'ils utilisent le système connecté au VPN à la fois comme passerelle et DNS (ce qui devrait être implicite s'il est configuré comme serveur DHCP).
Méthode 2b - Routage basé sur des règles à l'aide de squid
C'est ma méthode préférée et elle fonctionne bien avec ma PS4 et les autres appareils que j'utilise pour me connecter.
Avantages :
- Gère les sous-domaines
- Gère le champ de référence
- Ne nécessite pas le remplacement de votre routeur existant
- Les clients (navigateurs) peuvent éventuellement l'utiliser ou non
Inconvénients :
- Les clients doivent prendre en charge la connexion proxy
Cela suppose que vous ayez une configuration de squid fonctionnelle et une connaissance de base de la configuration de squid.
Ajoutez les lignes suivantes à squid.conf :
# redirect example domains
acl domain_to_remote_proxy dstdomain .example.com
acl ref_to_remote_proxy referer_regex [^.]*\.example.com.*
# redirect geoblocked domain
acl domain_to_remote_proxy dstdomain .geoblocked.com
acl ref_to_remote_proxy referer_regex [^.]*\.geoblocked.com.*
# mark packets that we want routed through the VPN
tcp_outgoing_mark 0x03 !ref_to_remote_proxy !domain_to_remote_proxy
Notez qu'il y a 2 lignes par domaine et que les sous-domaines sont appariés. La première ligne vérifie le domaine de destination et la seconde correspond à l'en-tête "Referer". Ceci est utile car les navigateurs envoient le référent lors de la récupération de contenu sur une page Web, comme des images, CSS ou javascript ; cela signifie que le contenu demandé par le site sera également acheminé via l'adresse non VPN même s'il est hébergé sur un domaine différent (par exemple, example-cdn.com).
Sur les clients, configurez la connexion comme d'habitude, mais définissez les paramètres de proxy pour utiliser le serveur proxy et le port de ce système. La plupart des appareils (y compris les consoles de jeux) permettent une configuration à l'échelle du système. Sur les PC, la plupart des navigateurs peuvent être configurés pour utiliser un proxy indépendamment des paramètres du système.
Remarque finale - Mon cas d'utilisation consiste en fait à acheminer des domaines spécifiques via le VPN et tout le reste via le non-VPN. Les méthodes sont similaires à celles ci-dessus, mais inversées.
Je vous recommande d'éviter de gérer le routage en fonction des noms de domaine (d'ailleurs, il est également impossible de résoudre le sous-domaine générique, qu'il s'agisse de points bonus pour celui-ci ou non :D)
Pour être un peu descriptif, vous ne devriez pas faire cela parce que :
1) certains domaines changent leurs adresses IP de temps en temps,
2) il est impossible de faire correspondre les caractères génériques dans les sous-domaines
3) il est impossible de connaître/récupérer tous les sous-domaines de n'importe quel domaine
4) n'importe quel sous-domaine aléatoire peut avoir n'importe quelle adresse IP aléatoire.
Ainsi, la solution en tant qu'extension de navigateur (et/ou proxy local personnalisé comme squid) est la meilleure option pour votre problème.
Mais, je suppose, l'addon "FoxyProxy" (c'est à l'origine l'addon Firefox, mais AFAIRC, c'est la version alfo Chrome qui existe) est exactement ce que vous voulez.
Et, aussi, en répondant à votre avis que "FoxyProxy est un service payant et vous avez déjà votre vpn":
FoxyProxyPlus est un service payant, mais pas FoxyProxy.
FoxyProxy est un module complémentaire disponible pour les principaux navigateurs :
Édition Standard (Firefox) | Édition de base (Firefox)
Édition Standard (Chrom{e,ium}) | Édition de base (Chrom{e,ium})
Ainsi, si vous souhaitez accéder à certains domaines via VPN, vous devez :
1) écrivez des règles pour que foxyproxy passe par votre instance squid pour la liste des domaines
2) et/ou écrire la liste des règles pour le calmar
3) capturer le trafic http/https n'appartenant pas par squid avec iptables et faites-le pointer vers squid par règle comme ceci :
iptables -m owner -m multiport -t nat -A OUTPUT ! -o lo ! --uid-owner $squid_user_id -p tcp --dports 80,443,8080,... -j REDIRECT --to-ports $SQUID_PORT
(--syn l'option peut être nécessaire pour -p tcp)
4) capturer le trafic http/https détenu par squid, et marquez-le pour le prochain routage vers VPN avec une règle comme celle-ci :
iptables -A OUTPUT -m owner --uid-owner $squid_user_id -j MARK --set-mark 11
5)
echo 11 forcevpn >> /etc/iproute2/rt_tables
ip rule add fwmark 11 table forcevpn
ip route add default via 10.0.0.1 table forcevpn
où 10.0.0.1 est votre passerelle à l'intérieur du VPN. Ou vous pouvez utiliser dev $VPN_IF au lieu de via 10.0.0.1 si vous n'avez pas de passerelle et que vous souhaitez simplement pousser tout le trafic dans l'interface vpn.
6) éventuellement, vous devrez peut-être exécuter sudo sysctl ipv4.conf.all.rp_filter
=0
===
Et encore une chose :
Si vous voulez faire la même magie avec du trafic TCP non-http(s), vous aurez besoin de quelque chose comme des proxychains, et effectuerez une capture magique similaire.
Et, si vous voulez faire cette magie avec UDP, j'ai une mauvaise nouvelle :je ne connais aucun proxy capable de proxyer UDP (à cause de la nature de ce protocole) :)
⇓⇓⇓ MODIFIER ⇓⇓⇓
Au cas où vous voudriez l'inverse (par défaut gw =vpn, et réglez certains domaines directement via le FAI), cela peut être :
1) écrivez des règles pour que foxyproxy passe par votre instance squid pour la liste des domaines
2) capturer le trafic propriété par squid, et marquez-le pour le prochain routage d'une autre manière avec une règle comme celle-ci :
iptables -A OUTPUT -m owner --uid-owner $squid_user_id -j MARK --set-mark 11
3)
echo 11 novpn >> /etc/iproute2/rt_tables
ip rule add fwmark 11 table novpn
ip route add default via ${ISP_GW} table novpn
où ISP_GW est la passerelle que vous utilisez pour acheminer le trafic vers votre serveur VPN. Certains utilisateurs peuvent vouloir utiliser dev ppp0 (ou ppp1 , ..., pppN ) au lieu de via ${ISP_GW} au cas où ils utilisent pptp pour se connecter à Internet.