Hi all and thanks in advance for your help.
I have a situation where I have a need to test an unstable Internet connection on one internal network and send out an email alert on any issues (obviously requiring an Internet connection) through another network - .
I have hardware with dual nic and plan on writing something simple in vb.
Is there a way I can disable ping on my 'good' connection forcing it through the test network yet allowing smtp?
I've looked into routing and done some basic testing but it seems the ping automatically reroutes through the good network shortly after the bad network fails?
Any advice warmly received.
You should not even think about blocking ICMP. This is a good way to cause many, many problems. Instead, you should explicitly specify which interface to use for the ping requests.
If you're using a command-line ping, you usually do this by specifying the source IP to use for sending the packets. For example, on OS X, you can run the command
ping -c 5 -S 10.0.1.13 8.8.8.8
to ping Google's public DNS server (8.8.8.8) using the interface whose IP address is 10.0.1.13. If the interface with that IP is down, the ping will fail.
The specific flag varies from implementation to implementation.
If you're writing your own ping code, IIRC, you just need to bind the socket to that source address with the bind() system call.
Related
I have DPDK set up, with two NICs taken over by DPDK, i.e. the interfaces
are not visible to userspace applications.
Now, I need to run netperf/iperf to measure throughput performance of port-to-port
configuration of DPDK, as described here https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/00_Phy-Phy.md
However netperf server requires to be bound to the network interface, and netperf client
has to know the netserver's IP address. But since the interfaces were taken
by DPDK, and netperf can't see their IP addresses any longer, how could I
run tests? Is there a way to redirect netperf right in network port,
regardless of IP addressess.
iptables, ebtables.. ?
Thanks.
If you're going by that diagram, your netperf and netserver should both be on the traffic generator. On the DPDK host, traffic coming in one interface is simply routed out the other interface by OVS, and back to your generator. There are a variety of tricks to get your generator to send traffic out on the wire rather than short circuiting over loopback, but they have been addressed here already.
If what you really want to do is have netserver running on the DPDK host, then you simply need to create a virtual interface, attach it to OVS, give it an IP, and direct your netperf traffic to it.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
I will be physically sending a Linux netbook to a remote site where it will be connected to the internet. I have no idea of the public IP address.
I need to be able to securely log in to the system. What's the best way to do this? I guess it needs to broadcast an id somehow (dyndns? free options?). It all needs to be preconfigured before I send it.
I'm more than happy to research on my own, but I'd be grateful in someone could point me in the right direction.
Regards,
Update- I only need console access, and it's ubuntu
Because the system may be behind an NAT or firewall, there is no way you can guarantee any connectivity. Even if you did know its public IP address, it is unlikely that you would be able to initiate a connection to the box from the outside.
So the next best thing is to have the box itself initiate a connection to one or more known servers. An outgoing connection stands a much better chance of traversing any firewalls and is essential to traversing NAT.
To make this work, you will need a server with some process listening for connections on a fixed address and port and ready to forward your ssh sessions to any such connection. The box itself will need to periodically attempt an outgoing connection to that server, perhaps hourly.
The simplest would be to have an /etc/rc.init script (or whatever is the equivalent on your particular linux distribution) which periodically tries to establish an ssh tunnel. It might look something like:
ssh -i remotekey.pem -R 33333:localhost:22 user#my.server.com
This assumes you've setup "user" for key based login using "remotekey.pem" on your server.
Then from your server you would log into the remote box using
ssh -p 33333 boxuser#localhost
This assumes "boxuser" is a valid user on your remote box.
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.