I can't seem to find the right combination of search terms to google for this answer, but what would I have to do if I wanted to create my own elastic ip that I could point to any other up address using my own private hosting? What would some of the bottlenecks be?
To add more detail: Amazon's Elastic is not simply a server that you pass requests too and it then makes the requests for you and passes back the data that's returned like some sort of VPN. Their service allows you to make a request to one IP address and have it be as if you made that request to another IP address entirely. How do they do this?
tI believe this can be done via simple iptables rules and Network Address Translation (NAT), I am unsure how AWS does it on their backend.
A simple rule
iptables -t nat -I PREROUTING -d 99.99.99.99 -j DNAT --to-destination 12.34.56.78
In this rule, we will be adding a rule to the top of the NAT Prerouting table, this will be the first rule evaluate by every packet - be weary, many rules will slow down your packet flow - you should study up on iptables if you go down this route.
Here, we will be taking a packet destined to 99.99.99.99 - and the DNAT rule will simply rewrite the destination IP of the packet, and send it on its way.
To delete the rule, simply change the -I to -D.
A basic failover of the above rule to a new server
iptables -t nat -D PREROUTING -d 99.99.99.99 -j DNAT --to-destination 12.34.56.78 # Delete existing forward
iptables -t nat -I PREROUTING -d 99.99.99.99 -j DNAT --to-destination 87.65.43.21 # Add new forward
Note that you will also need to have rules in the Filter Forward table as well for each destination you plan to send packets to.
iptables -t filter -I FORWARD -d 12.34.56.78 -j ACCEPT
iptables -t filter -I FORWARD -d 87.65.43.21 -j ACCEPT
edit
You have asked about load balancing, so here is this as well, load balancing connections between 3 hosts.
iptables -t nat -I PREROUTING -d 99.99.99.99 --mode nth --every 1 --packet 0 -j DNAT --to-destination x.y.z.1
iptables -t nat -I PREROUTING -d 99.99.99.99 --mode nth --every 2 --packet 0 -j DNAT --to-destination x.y.z.2
iptables -t nat -I PREROUTING -d 99.99.99.99 --mode nth --every 3 --packet 0 -j DNAT --to-destination x.y.z.3
If you wanted to restrict this to either HTTP / HTTPS, you would filter those ports accordingly:
iptables -t nat -I PREROUTING -d 99.99.99.99 -p tcp --dport 80 -j DNAT --to-destination 12.34.56.78:80
It may help, it may just be even more confusing, but here is a page with some useful rules.
Related
I have network setup like this with external and internal network.
I have successfully got squid running with proxy for internal browser and now I want to set up as transparent but having some problem.
network
First, I did change "http_port 8080 intercept" but having trouble with setting up correct Iptables on the external server as the packet is not getting back to squid box.
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -0 lo -j ACCEPT
iptables -t nat -A POSTROUTING -o enpos3 (this is NAT) -j MASQUERADE
iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 8080 -j ACCEPT
iptables -t nat -A PREROUTING -i enp0s3 -p tcp --dport 80 -j DNAT --to-destination 10.10.1.254:8080
iptables -t nat -A PREROUTING -i enp0s8 -p tcp --dport 80 -j REDIRECT --to-port 8080
This is far as I got and internet works fine on internal pc but I'm not sure how to redirect http 80 packet to Squid box (10.10.1.254:8080)
Couple of things.
From the diagram it is not clear where is the Squid Box. Considering you are setting up a Transparent proxy it will be in between your internal network and WAN connection which I believe you might have taken care of. Please check
Considering this a dual homed box you need to set Default Gateway to point to your Squid Box WAN interface.
You do need Reverse Path Forwarding enabled.
Last but least IP packet forwarding enabled.
I develop an application to inspect packets arriving on a linux machine.
I would like to send in NFQUEUE all the incoming connection packets and only the incoming ones. Not only --state NEW but also --state ESTABLISHED, RELATED for connections that are initiated by a client.
One last thing, to make the tcp handshake for all ports I need this rule to works in addition:
iptables -A PREROUTING -t nat -p tcp -match multiport! --dport 64646 -j REDIRECT --to-ports 1234
Any help would be very appreciated.
Thank you!
I found the solution if it interests someone.
# Accept our ssh on a modified port
iptables -A PREROUTING -t raw -p tcp --dport 64646 -j ACCEPT
# Mark all packets of incoming NEW connection with mark 1 (netfilter connmark)
iptables -A PREROUTING -t mangle -m state --state NEW -j CONNMARK --set-mark 1
# Push into nfqueue all marked packets (netfilter nfqueue)
iptables -A PREROUTING -t mangle -m connmark --mark 1 -j NFQUEUE --queue-num 0
# Redirect all incoming connections to the userland listener to make TCP handshake
iptables -A PREROUTING -t nat -p tcp --match multiport ! --dport 64646 -j REDIRECT --to-ports 1234
Finally all the incoming packets go into nfqueue but if I work on the machine (update, upgrade, install...) packets do not match the rules.
In addition the redirection applies after nfqueue decision, so I log the base port (not 1234).
I have a website with subdomains for my clients (wildcard subdomain)
client1.test.com
client2.test.com
I want my clients to use their own domain If they want.
what kind of record needs to be added to point
client1.com => client1.test.com
shop.client1.com => client1.test.com
I´m using the free plan of cloudflare for www.test.com but I´m open to
change it if it can´t be done
CNAME records would work for that. You could also use A records to point to the same IP as test.com
You need modify the cname to redirect your client1 IP on their domain provider to client1.test.com
You need modify the cname to redirect your client2 IP on their domain provider to client2.test.com
CNAME setup on cloud flare is for paid plans only
https://support.cloudflare.com/hc/en-us/articles/200168706-How-do-I-do-CNAME-setup-
You might also want to check
https://support.cloudflare.com/hc/en-us/articles/200168826-Does-Cloudflare-support-wildcard-DNS-entries-
You simply need to understand DNS records and how they work. You can find a good resource for this here, the most important of which is 'A record' in your case.
In summary however, before your clients can point their own domain to your system, they will have to configure their domain host records to point to your server/IP address.
For you, you don't have to do anything in Cloudflare but on your server. Say you have configured your webserver to recognize client1.test.com but client1 decides to use a domain client1.com and shop.client1.com, you have to set your webserver block for client1.test.com to also recognize these two domains aliases in addition to the original subdomain.
With Nginx, this will look like:
Server {
...
ServerName client1.test.com shop.client1.com client1.com
...
You could take a look at this script if you are looking for how to automate this process.
Maybe you could use CNAME Record like this:
client1.com CNAME client1.test.com.
shop.client1.com CNAME client1.test.com.
The dot at the end is to tell the DNS not to complete your entry with the default-Domainname.
If you not must use an DNS to redirect, you also be free to use You even could do it by IPTables Forwarding. Good at this solution... you can decide which port will point to which ip... this way you could forward webserver to the Server of your Customer, but leave Mail at your server (for example)
Here how forward a port to another host that has an external IP:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport $port -j LOG --log-prefix="PreRouting $port..:"
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport $port -j DNAT --to $ip:$port
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
sudo iptables -A FORWARD -p tcp -i eth0 -o eth0 -s $ip --sport $port -j LOG --log-prefix="S Forward $port.."
sudo iptables -A FORWARD -p tcp -i eth0 -o eth0 -s $ip --sport $port -j ACCEPT
sudo iptables -A FORWARD -p tcp -i eth0 -o eth0 -d $ip --dport $port -j LOG --log-prefix="D Forward $port.."
sudo iptables -A FORWARD -p tcp -i eth0 -o eth0 -d $ip --dport $port -j ACCEPT
You also have to add this command to set on your network stack:
sudo sysctl -w net.ipv4.ip_forward=1
This will work in a default DENY IPTables setup.
I need to redirect particular outgoing connections (from any web-client on my system) to particular IP. Yes, it can be done by adding this line in /etc/hosts file:
123.456.789.012 www.mydomain.com
Is it possible to do such a redirection without editing of /etc/hosts? In fact, I need this redirection temporarily. Moreover, I cannot modify any configuration files on my system, so I should do such a redirection only via some utils in the command line. I've read about tsocks, but it can redirect outgoing connections to SOCKS server only from the particular application, not from any application.
So, is it possible?
Ok, I found a solution. We can use iptables for it. This rule redirects all outgoing requests via 80 port to 0.0.0.0:3010:
$ sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 0.0.0.0:3010
To delete this rule, just replace -A to -D:
$ sudo iptables -t nat -D OUTPUT -p tcp --dport 80 -j DNAT --to-destination 0.0.0.0:3010
If we want to redirect only particular requests via 80 port, we can use this command:
$ sudo iptables -t nat -A OUTPUT -p tcp -d google.com --dport 80 -j DNAT --to-destination 0.0.0.0:3010
In this case only requests to google.com will be redirected to 0.0.0.0:3010.
Im writing a bash scripting to account traffic in my network server:
WAN:eth1 -> GNU/Linux Server:eth0 -> Users
The GNU/Linux server uses squid, bind, QoS, mysql, lighttpd.
After an IP exceed the established quota a new QoS rule is applied for that IP (user) too exist one "flag" to decide when is restored the IP counter to Zero.
Some IPs and subnets work without quotas, other gruop of ips/subnets work with new QoS after quota is exceeded, and now I wanna work with a third group with redirection after quota is exceeded.
When an IP exceed the established quota all http traffic must be redirected to host (lighttpd runing on GNU/Linux ) and DROP all other traffic generated for that IP. In webserver exist a webpage with: "You exceed your daily quote of traffic, please wait "x" hours or call to your provider to purchase an extra navigation package" or something like that.
Is possible using a chain, or how can I do that?.
The most topics that I found in Internet, are related to block all and create a new chain to let out to Internet (not work for me). And other redirect only IP by IP, but how can I create something that a "chain" and attach the IPs to must me redirected to can after restore that IPs easly?
Thanks for help and sorry for my poor English :S.
Are you looking for something like this?
iptables -t nat -A PREROUTING -s 192.168.100.66 -p tcp --dport 80 -j REDIRECT --to-ports 80
iptables -I INPUT 1 -i lo -s 192.168.100.66 -j ACCEPT
iptables -I INPUT 2 -i eth1 -d 192.168.100.66 -j DROP
This will redirect packets from 192.168.100.66 on port 80 to the local webserver on the loopback interface, allow that conversation, then reject all other packets being routed to 192.168.100.66 on the WAN interface.
To restore the connection back to normal you will want to delete those firewall entries:
iptables -t nat -D PREROUTING -s 192.168.100.66 -p tcp --dport 80 -j REDIRECT --to-ports 80
iptables -D INPUT -i lo -s 192.168.100.66 -j ACCEPT
iptables -D INPUT -i eth1 -d 192.168.100.66 -j DROP
Note that iptables itself (well, the xtables-addons extension set providing quota2) can already do the quota matching magic and you can (re)set the values through procfs, combined with REDIRECT as #resmon6 says:
-t nat -s user1addr -m quota2 --name user1 ! --quota 0 -j REDIRECT...
-t nat -s user2addr -m quota2 --name user2 ! --quota 0 -j REDIRECT...
The syntax is a arguably a little odd right now (0 is the initial value only and is independent from the runtime quota test involving the negational !. Noticing this just now, a patch may make it in to unroll this confusing syntax in the future).