ipv4 options
Does anyone know where I can find documentation on all those ipv4 options in the /proc/sys/net/ipv4 and in the ../all directory such as log_martians. I am trying to learn firewalling and have not found these items addressed anywhere. You see documentation that recomends this and not that but with no explanation.
Thanks, Tom |
Have you checked through the advanced linux routing howto?
|
These are my favorites:
http://www.securityfocus.com/infocus/1711 http://ipsysctl-tutorial.frozentux.n...-tutorial.html |
Or the ever popular
man ip man tcp man udp |
Very Confused
Thanks guys that was exactly what I was looking for yet I am still unable to solve my problem. I thought it had something to do with DNAT and it may yet prove to be the case but I am unable to figure it out.
PROBLEM##### My webserver is behind my nat. Domains are properly resolving to my gateway. What I am trying to accomplish is to be able get web pages using other than the literal name. In other words I have to enter the private ip to fetch pages on my local http server, if I use the domain name it fails. So what is happening, is it a routing issue somhow. Thanks, Tom |
Do you have to use private ip when you are in local net, or when you try to access your web-server from outside? If later, to where you have to put that private ip? To host: field in your http query?
Getting http requests to their destination consists of two parts: Reaching the right machine and talking to the correct virtualhost. Are you having problems with the first, or with the second part? |
I have to use the private ip from the local net only. From outside I can use the public ip or the domain name. And actually vitual hosting is when this became such a problem. I had gotten the users accustomed to using the local ip but with virtual hosting that only gets the default directory.
If i traceroute to my domain from the local net it makes one hop to the external ip. This seems right but it is almost as if it stops there. Thanks |
Yeah, I've had that happen too. This trick works pretty well:
http://www.netfilter.org/documentati...-HOWTO-10.html |
Thanks, wish I had checked back sooner. This looks a whole lot easier than the dns solution I used. I am a little confused (will try and see) but if dns shows the name resolution to be a public ip how would the destination be an internal ip?
Code:
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \ |
Because the http traffic is then getting DNATed to the internal IP of the internal webserver.
The main crux of the problem is that the webserver then gets the packet from the NAT box that has the internal clients IP as the source address. When it serves the http request, it then sends a packet to that source address. Since it's on the same network, the webserver sends it directly to the internal client (skipping the NAT box entirely). The client is expecting an http response from the the external IP (it has no knowledge that the DNAT occurred) and instead gets a random response from the local webserver. Since it isn't expecting this response, it discards the packet or at least fails to associate it with the original connection attempt. So you end up with what looks like a triangle. The way around this is to trick the webserver to respond to the DNAT box instead, that way the packet can then be "un-DNATed" properly and the client gets back a packet that looks like it came from the external IP and all is good. A good way to get your mind around this is to draw a diagram with the three machines and their IPs. Then follow the path the packet will take, keeping in mind the source and dest IPs at each hop. I tried to do an ASCII Art diagram of it, but I suck and it looked like a log cabin exploded instead, so you're on your own there. |
The prerouting rule is more important. Postrouting part is probably not an issue if you have direct access from web-server to the client (that is in your intranet). If yackages are passed through the box doing the NAT, it does un-natting implicitly; that postrouting rule just helps the packages to reach the nat-box.
|
Postrouting part is probably not an issue if you have direct access from web-server to the client (that is in your intranet)
Actually that is the problem itself. The internal client sends packets to the external IP address, but is getting replies back from the local webservers IP. I looked around for a better explanation of this and came across this one by Oskar Andreasson: Quote:
|
Man, thanks so much; great explanation.
|
All times are GMT -5. The time now is 03:06 AM. |