As others explained, in theory this is impossible, because routing does not know the destination DNS name that was used to obtain destination IP address. However, you can do what @Bass described as "chopped" DNS. First, set up your own DNS (I use Raspberry Pi as VPN router, so I have all benefits of Linux, I advise you don't do it on your Windows workstation :). Use dnsmasq with DHCP disabled, and at first, set it up as pure caching DNS server, with the dnsmasq.conf as follows:
log-queries # Logging
log-async # Async logging
domain-needed # Don't forward short names
bogus-priv # Never forward addresses in the non-routed address spaces.
server=126.96.36.199 # Use Google DNS 1 upstream
server=188.8.131.52 # Use Google DNS 2 upstream
After you manage to force your own DNS to the machines (desktops and other stuff, e.g. chromecast, tv, etc), and confirm it is working, you can start hacking away. Run the program/app or access the website you want to redirect, and then on the routing machine you do:
sudo killall -SIGUSR1 dnsmasq
Now you have nice dump of recently accessed IP addresses along with their names (any decent application will try to access DNS, I believe no one would hard-code IPs any more).
Now you restart dnsmasq or the routing machine (just to be sure to clear the cache) and force access to google DNS which bypasses the OpenVPN, e.g. by doing something like this:
sudo route add -net 184.108.40.206 netmask 255.255.255.255 gw 192.168.1.1 dev eth0
sudo route add -net 220.127.116.11 netmask 255.255.255.255 gw 192.168.1.1 dev eth0
Just to be clear, the eth0 is the network interface that goes to my internet provider, and 192.168.1.1 is the gateway address which bypasses the VPN. Now you repeat the exercise with starting the app/website/device and dumping the names and IP numbers. They should be different now.
Restart the routing machine again (to get rid of the above temporary routes) and do the following two things for each IP:
Add address line to dnsmasq.conf for each address to force resolving to the off-vpn-IP you obtained in the second step, as follows:
Add the address-specific route to your routing configuration (needs to be done after each reboot or saved as permanent route)
sudo route add -net off.vpn.ip.obtained netmask 255.255.255.255 gw 192.168.1.1 dev eth0
Again, assuming 192.168.1.1 is the non-vpn gateway.
- This is terrible solution
- It works for me
- IPs may change at any moment and the setup becomes invalid
- Fortunately, the scenario from 3. is not frequent if different IPs are used for load balancing or content restrictions (e.g. you would bypass these mechanisms, but the IPs would be working anyway)
- Have no idea what the people maintaining server will think when they get the traffic from the IPs that should not exist (e.g. someone trying to transfer the load to other IP while you happily keep accessing the server that in theory should not be under load).
Hope it helps, but yes, it is a terrible solution. Have fun and good luck!