2
I know I can do curl curlmyip.com
or something like that, but that just shows me the ip curlmyip.com is seeing.
Is there any tool I can use that tells me what's my ip on the endpoint for any TCP connection endpoint (not just curlmyip.com)?
2
I know I can do curl curlmyip.com
or something like that, but that just shows me the ip curlmyip.com is seeing.
Is there any tool I can use that tells me what's my ip on the endpoint for any TCP connection endpoint (not just curlmyip.com)?
2
The Internet Protocol does not have an inherit way of disclosing the address of either party
If you have control over those endpoints you could set up such as service, or simply capture an ICMP echo (ping) on the remote endpoint to see what IP it's being presented with
Another solution would be to use netcat to open a simple server and connect to it, when running with a verbose switch it will display information about the connected peer
server:~# nc -lvp 1234
Listening on [0.0.0.0] (family 0, port 1234)
Connection from [127.0.0.1] port 1234 [tcp/*] accepted (family 2, sport 42852)
0
You can use curl --interface
to define which interface should be used for the request. Then request curlmyip.com
or a similar service as usual.
No. I have only one interface. But I have multiple layers of NAT in between this interface and the endpoint, which depend on the endpoint; and I want to see the ip the endpoint is seeing on ANY particular endpoint I choose, not just curlmyip.com. I've tried traceroute but it doesn't show anything outside the LAN (I guess the incoming ICMP replies are being blocked) – NotGaeL – 2014-12-17T14:51:06.233
0
This isn't going to be possible in the general case.
In general, multiple layers of NAT implies that there are several routers applying NAT in a fairly transparent way. The point of NAT is that it replaces addresses and thereby discards any information that the exterior see's as your address.
The only ways to achieve this are
Solutions therefore may be available where you have some control over the far endpoints.
0
Not sure I understand your question right, but there is this solution among others:
dig +short myip.opendns.com @resolver1.opendns.com
DNS is faster and lighter instead of using http. If dig is not available try the tool available for your dns queries, and have look at this answer on serverfault
1It's not exactly a solution but a good enough confirmation that there's no solution :-) – NotGaeL – 2014-12-17T22:54:13.867