Gérer 2 routes par défaut et faire en sorte que certains trafics passent par l'une et d'autres par l'autre est un gros problème et je vous recommande de l'éviter si possible. Si vous ne voulez pas accéder à l'internet via le VPN, alors votre configuration peut être grandement simplifiée, ce qui résoudrait les problèmes. Avez-vous vraiment besoin d'accéder à Internet via le VPN ? Aussi, quelle est la signification de 10.132.1.5 ? Je ne comprends pas pourquoi vous l'utilisez pour router vers d'autres hôtes dans 10.132.1.x ? vous avez déjà une IP dans ce sous-réseau 10.132.1.x et vous devriez être directement connecté.

donc SI vous ne voulez pas accéder à l'internet via le VPN et qu'il n'y a pas besoin de router via 10.32.1.5, vous pouvez simplifier votre table de routage comme suit :

default via 192.168.0.1 dev eth0  proto static  metric 100 
10.132.1.0/24 dev tun0  proto kernel  scope link  src 10.132.1.6 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.6     metric 100 

Ce qui résoudra également le problème d'apache. Pourquoi seulement ces routes ? Premièrement :

10.132.1.0/24 dev tun0  proto kernel  scope link  src 10.132.1.6 

devrait être le seul itinéraire dont vous avez besoin pour accéder à tous les hôtes de l'autre côté du vpn. Comme cette route correspond aux adresses 10.232.1.0 - 10.232.1.254, s'il y a d'autres adresses 10.x.x.x sur le réseau vpn, vous pouvez élargir la route à 10.0.0.0/8. Si vous ne comprenez pas la signification des bits /8 /24, je vous conseille vivement de lire le document suivant Quelle est la "barre oblique" après l'IP ? ou recherchez sur Google la "notation CIDR". Le bit /32 /1 aura plus de sens.

ces anciennes routes mises ensemble définissent votre route par défaut via le VPN

0.0.0.0/1 via 10.132.1.5 dev tun0 
128.0.0.0/1 via 10.132.1.5 dev tun0

Le fait de le diviser en deux routes (une pour la première moitié de l'Internet et la seconde pour le reste) signifie qu'elles ont une priorité plus élevée car elles sont plus spécifiques que votre route par défaut :

default via 192.168.0.1 dev eth0  proto static  metric 100 

Le problème est que vous devez maintenant ajouter explicitement des routes qui sont encore plus spécifiques, pour forcer le trafic via votre routeur local (192.16.8.0.1).

123.4.5.6 via 192.168.0.1 dev eth0 
234.5.6.7 via 192.168.0.1 dev eth0 

Sans la route par défaut via le VPN, ces routes ne sont pas nécessaires. Si vous avez besoin d'acheminer le trafic via 10.232.1.5 et que vous devez conserver des ensembles de routes par défaut, je vous recommande d'utiliser des règles de route plutôt que de remplacer la route par défaut. Les règles de route sont plus flexibles, mais en général, il s'agit de faire correspondre l'IP source à la passerelle par défaut, de sorte que tout le trafic provenant de votre IP VPN (10.1.232.6) passe par la route par défaut du VPN et que tout le trafic provenant de votre IP locale (192.168.0.6) utilise votre FAI comme route par défaut. https://unix.stackexchange.com/questions/22770/two-interfaces-two-addresses-two-gateways pour un guide sur la façon de le faire.

Dites simplement à Apache d'écouter sur plusieurs adresses IP.

Je pense que vous voudrez avoir ces lignes dans votre configuration.

Listen 192.168.0.6:80
Listen 10.132.1.6:80

Cela indique à Apache de se "lier" au port 80 sur chacune de ces adresses IP. Si vous utilisez des hôtes virtuels, vous devrez également ajouter ces lignes à leur configuration.

Sidenote

Si vous n'en utilisez pas, je vous recommande d'utiliser une adresse IP statique sur votre ordinateur. eth0 ainsi que sur le serveur VPN.

Si vous n'êtes pas en mesure de configurer une IP statique sur le VPN, il existe des solutions de contournement. L'une d'entre elles consiste à générer le fichier Listen après s'être connecté au VPN. Ou bien, il existe peut-être une solution propre qui utilise les noms d'hôtes (si vous avez un serveur DNS).

Documentation officielle :

• Documentation Apache (bind)