How do force Python to use a specific VPN? The VPNs are configured and listed with ifconfig as ppp0 .. pppn, using PPTP. For a client I need to connect to an arbitrary VPN on a per Python-process basis. I couldn't find any examples on the internet for this use case.
The use case requires that a connection is made to a remote host using a specific IP address (which is on the other end of the VPN).
Related
I am currently implementing a Django web application, which will be used only locally but long-term. I already managed to start the Django server on my local machine using python manage 0.0.0.0:myport and I am able to connect from any mobile device using MyLocalIPv4:myport.
In best case I only want to start the Django server once, establish a connection between a mobile device and the web app and let the web app run for an undefined long time on that mobile device
Now my assumption is, that MyLocalIPv4 will be changing over time as it is a dynamic IP address, which will force the user (or even worse myself) to look up the new IP address and re-establish the connection.
My question are: Do you know any mechanisms on how I can avoid this type of behaviour using another (maybe static) referral to the web app ? What do you think about this web application in term of security issues ?
DNS is the way to go. What you want is a (internal) domain that would map to your computer IP address.
There are many ways you can achieve that but I suggest going with whatever tools you have available. I assume that for your home network you're using some sort of a consumer-grade home router with wireless access point. Very often this type of hardware offers some way to "map" the hostname of a machine to its internal-network IP address.
For example, at home I'm using a RT-AC1200G+ router, which runs an internal DNS server and maps hostnames of clients of my network to their IP:
$ dig +short #192.168.1.2 samu-pc
192.168.1.70
$ ifconfig |grep 192.168.1.70
inet 192.168.1.70 netmask 255.255.255.0 broadcast 192.168.1.255
Alternatively, one of the easier solutions would be to ensure your IP does not change. You could assign a static IP to your django-server machine, OR if you want to continue using DHCP - use your routers functions to make a static assignment to a specific, static IP address using your network card's MAC address.
Disclaimer: There are other, more "professional" ways of solving service discovery within a network, but I would consider them overkill to your home network setup. Also, if you care about security, you should consider running the django app behind a reverse proxy with HTTPs on the front, just to ensure nobody in your internal network is trying to do something nasty.
At work, I'm connected to both an internal internet service (through wifi) and an ethernet cable for external internet access. The wifi connection is the only way to connect to our internal databases or systems, but ethernet is what I need for internet browsing. Currently, by default I'm on the ethernet cable, but when I need to connect to our internal databases, I have to unplug the ethernet cable or go into my settings to change the service order to specifically use wifi (unplugging is much quicker).
Is there any way to specify in python to specifically use the non-default wifi connection when connecting to my sql server?
Python can't determine how to connect to IPs, that is in the domain of the operating system, at a lower level than Python cares about. You have to convince your OS to do it. Note that, because of this, the method is necessarily OS-specific, so nothing in this answer will work on anything other than Mac OS X.
I am not 100% sure, but I think you can do it so that OS handles the situation automatically. Try this:
Know the IP address of your database (e.g. 192.168.1.1)
Find out what the connection is called (probably Wi-Fi):
networksetup -listallnetworkservices
Find the gateway that is taking you there (e.g. 192.168.1.254) and its subnet mask (eg. 255.255.255.0):
networksetup -getinfo Wi-Fi
Set up a route so that your Mac OS will know to use that gateway for that address. This is kernel-level stuff so you need superuser access:
sudo networksetup -setadditionalroutes Wi-Fi 192.168.1.1 255.255.255.0 192.168.1.254
If I am correct, you can now browse the web using your normal connection, and use the ethernet Wi-Fi to connect to your database, automatically without you having to do anything further.
Another way to do this, closer to the way you asked it, is to create two different locations, with different service order; then you can switch between them programmatically using
networksetup -switchtolocation MyLovelyDatabase
You can get back to the default using
networksetup -switchtolocation Automatic
You can do this method from Python using subprocess.
I am writing an application, currently in Python + Twisted, which serves as a first port of call for DNS requests – if the requests meet certain patterns, e.g. Namecoin .bit addresses or OpenNIC TLDs, they are passed to different DNS resolvers, otherwise the default one is used.
Some addresses however I need redirected through special routes, e.g. Tor .onion addresses which don't resolve to traditional IPv4 addresses, or certain websites that require tunneling through a VPN for geolocation reasons. So when DNS requests for such sites come in, I want the application to create a new loopback interface/alias and return the IP of this interface. I then need to be able to tunnel all TCP and UDP traffic coming through this interface through the proxy/VPN or whatever to the endpoint it was set up for.
The question is, how can I do this? Listening on specific ports (e.g. 80) will be fine for most purposes, but as a perfectionist I would like to know how to accept connections/messages sent to ALL ports, without having to set up tens of thousands of listeners and potentially crashing the system.
Note: while everything is currently in Python, I don't mind adding components in C++ or another language, or playing around with network configurations to get this working.
I wrote this code for finding google ip in python
import socket
print socket.gethostbyname('google.com')
.
.
173.194.39.0
but if we use command prompt and ping command for finding google ip result is:216.58.208.36
why there is difference between two results?
Both of those IP addresses resolve to Google.com. We can verify this from the command line with the unix whois command.
$ whois 216.58.208.36
NetRange: 216.58.192.0 - 216.58.223.255
CIDR: 216.58.192.0/19
NetName: GOOGLE
$ whois 173.194.39.0
NetRange: 173.194.0.0 - 173.194.255.255
CIDR: 173.194.0.0/16
NetName: GOOGLE
I ran into this same issue and the cause was that the first command that required an IP address was using a cached DNS entry (because the DNS entry's time to live (TTL) hadn't expired yet) and then by the time the second command was issued the TTL had expired on the cached entry so a new DNS request was made for the domain therefore grabbing a new IP address from the DNS server which happened to be different because the domain had a lot of IP addresses just like Google.com.
Python just relies on the Operating System's DNS resolver (or whatever daemon is running) and as far as I know the socket module doesn't give you the ability to clear the DNS cache before it tries to resolve an address. If you want more control over this functionality you can use DNSPython or something similar. If you are using a daemon for DNS on your operating system (like on Linux, for example) then usually restarting the daemon will force a flush of DNS cache and you find both addresses to the be same (unless you run into the timing issue as described above with the TTL's expiring).
Hostnames are translated to IP addresses through something called a DNS server. When you type a name into a web browser or use a program such as ping, the hostname that you provide (google.com) eventually reaches an authoritative DNS server for that domain-separate from the server that you correspond with for the actual content.
google.com has multiple different servers that can respond to data requests. Depending on the implementation of the different programs you are using to generate the request and other factors such as the network traffic at the time that you make the request, multiple requests from the same host may be directed to different servers by the authoritative DNS server. This is accomplished by returning different IP addresses to your machine.
FWIW, both ping and socket.gethostbyname() for google.com resolve to 216.58.217.14 on my machine, running OS X Yosemite.
I am trying to send some traffic via python using scapy (on Ubuntu). I am using a range of source IPs (10.0.0.32/29). Everything seems to be working (at least I see the traffic in wireshark and it reaches my firewall) but I am having a problem completing the TCP handshake using the IP addresses that aren't the main IP of the eth0 adapter. Does anyone know if this is possible to do:
Source:
from scapy.all import *
import random
sp=random.randint(1024,65535)
ip=IP(src="10.0.0.234/29",dst="www.google.com")
SYN=TCP(sport=sp, dport=80,flags="S",seq=10)
SYNACK=sr1(ip/SYN)
my_ack=SYNACK.seq+1
ACK=TCP(sport=sp,dport=80,flags="A",seq=11,ack=my_ack)
send(ip/ACK)
payload="SEND TCP"
PUSH=TCP(sport=sp,dport=80,flags="PA",seq=11,ack=my_ack)
send(ip/PUSH/payload)
Because you are behind a NAT/router, you should check it allows you to use the full range of IPs. If it is running DHCP protocol, your eth0 will typically recieve a unique IP adress that will be the only routed in your private network.
Furthermore, you must ensure your kernel knows what IPs are attributed to it, else it will drop response packets. If you want to use the full range of IP, you have two choices :
Create virtual devices with virtual mac adresses, each requesting an IP through DHCP.
Configure your router so it statically routes the full IP table to your host, and alias each IP you intend to use
Once you have done that, there is no reason you wouldn't be able to syn/ack from your multiple source IPs. From distant server point of view, there wouldn't be any difference between what you are trying to do and several machines in a local network requesting a page at the same time.