LinuxQuestions.org - what IPs point to my server box?

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - what IPs point to my server box? (https://www.linuxquestions.org/questions/linux-networking-3/what-ips-point-to-my-server-box-653249/)

what IPs point to my server box?

I'd like to know if there's a command I can run that will tell me what IP addresses point to my server box. Is there such a thing?

What do you mean by 'point to'? You can see what ip addresses are assigned to your cards with /sbin/ifconfig.

Quote:

Originally Posted by sneakyimp (Post 3202514)

I'd like to know if there's a command I can run that will tell me what IP addresses point to my server box. Is there such a thing?

Your question is ambiguous.

If you want a list of all the addresses that have accessed your Apache web server you can get it from the access log. Something like:

Code:

cat /var/log/httpd/access_log | cut -d ' ' -f 1 | sort | uniq

if you want to know the external IP of your server run this command on your server

wget -q -O - checkip.dyndns.org|sed -e 's/.*Current IP Address: //' -e 's/<.*$//'

It is my understanding that a server can be accessed by multiple IP addresses if it is configured to respond to them and if the network topology knows to refer requests for those IPs to that particular server. I'm not talking about which IP addresses have requested files from apache.

I'd like to know how to find out which IP addresses my server is configured to occupy and serve requests for. Sorry I'm not explaining this better. I'd very much like to know the proper jargon. I think beadyallen has the right idea. The output is pretty verbose though. It looks something like this for a machine I have access to:

Code:

server:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:A0:D1:E5:19:8E

          inet addr:67.14.192.54  Bcast:67.14.192.255  Mask:255.255.255.0

          inet6 addr: fe80::2a0:d1ff:fee5:198e/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:2682517 errors:0 dropped:0 overruns:0 frame:0

          TX packets:218 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:172874852 (164.8 MiB)  TX bytes:14060 (13.7 KiB)

          Interrupt:50



eth2      Link encap:Ethernet  HWaddr 00:04:23:D7:79:36

          inet addr:67.14.192.55  Bcast:67.14.192.255  Mask:255.255.255.0

          inet6 addr: fe80::204:23ff:fed7:7936/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:7161936 errors:0 dropped:0 overruns:0 frame:0

          TX packets:5498948 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:797646817 (760.6 MiB)  TX bytes:4466773972 (4.1 GiB)

          Base address:0xe800 Memory:feac0000-feae0000



eth2:1    Link encap:Ethernet  HWaddr 00:04:23:D7:79:36

          inet addr:67.14.192.56  Bcast:67.14.192.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Base address:0xe800 Memory:feac0000-feae0000



lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:1972615 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1972615 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:478276651 (456.1 MiB)  TX bytes:478276651 (456.1 MiB)

inet addr:67.14.192.54 Bcast:67.14.192.255 Mask:255.255.255.0
inet addr:67.14.192.55 Bcast:67.14.192.255 Mask:255.255.255.0
inet addr:67.14.192.56 Bcast:67.14.192.255 Mask:255.255.255.0

Although the last two aren't likely to work since they're configured on the same subnet as the first one, but on a separate ethernet interface. Unless you're running the ip2 stack, it's not going to be about to route return traffic out eth2 properly, so you'll end up with "triangular routing"... i.e. packets come in eth2, but the replies go out eth1 which results in the connection hanging since the replies are coming from the "wrong" IP.

Edit: Actually it looks like they all are being routed properly, so either the system is using the ip2 stack, or there's a firewall in front that is rewriting the source IPs to match the original request.

Quote:

Originally Posted by chort (Post 3203378)

What is a "ip2" stack?

http://tldp.org/HOWTO/Adv-Routing-HOWTO/

It's a combination of extended APIs and userland tools to implement more complex routing than what is possible using the standard tools (ifconfig/route/arp).