Tag Info

Hot answers tagged

36

That behavior is actually due to a normal feature of ping and has no relation to your actual hardware. Indeed, prefixing the IP address (or part of it) with a leading zero will cause the number to be interpreted as octal. So 057 means 57 in base 8 which is 47. Thus ping will send the ICMP query to the machine located at address 10.10.208.47 and therefore ...


13

Ping, like many other unix programs, use the C libraries on your unix system for name resolution. One of the functions used is inet_aton. The man page for inet_aton says: All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a ...


6

The simple reason is of course that a public IP-address is a internet network address and not a street address with a fixed geographical location. An simple IP-address to Location database is similar to using the logic of an old-school landline telephone number (which was somewhat geographically fixed with a country code, area code and local subscriber ...


3

You're NATting to the wrong IP. Don't NAT to your host's management IP, NAT to your guest's IP.


2

That is usually one of the points of deploying CDN. Hiding the actual data source, so it is not as easy to be (D)DoSed.


2

You can set up port forwarding on the physical machine, so that some physical machine's port in physical network is forwarded to the VM SSH port. For example if the physical machine is 10.10.10.1 and VM network 192.168.0.0/24, then port forwards can be like this: 10.10.10.1 port 225 forwarded to 192.168.0.1 port 22 10.10.10.1 port 226 forwarded to ...


2

I'll try to clarify what I interpret as your source of confusion: An IPv4 address is a single 32 bit integer but it's not normally formatted that way when we write out an address. As I'm sure you are aware, the norm is to write the address as [first eight bits in decimal].[next eight bits in decimal].[next eight bits in decimal].[last eight bits in ...


2

The fragment offset The fragment offset is a 13 bit field, and if you interpret those bits as an unsigned integer the maximum value will be 8191. But really it is counting multiples of 8 bytes, so it would make just as much sense to say the values go from 0 to 65528 in steps of 8. What exactly is the maximum valid value of this field itself is not ...


2

You need to add the Routing and Remote Access role to the server and set it up for IP routing. RRAS will handle the routing from Nic2 to the Nic1 network, but the other servers will need to know the route back to Nic2. On the other servers you will need route add 10.71.2.0 mask 255.255.255.0 10.71.1.3 This will let the other servers know to route return ...


2

Different geolocation sites pull their location data from different databases. There are a lot of these databases and IP addresses get reassigned frequently so it can be difficult to keep the current location of an IP address owner up-to-date in every database all the time.


1

You can use a HTTP Basic authentication: <Location /> AuthType Basic AuthName "Secured" AuthUserFile /path/to/.htpasswd Require valid-user Satisfy any Deny from all Allow from 192.168.1 </Location> To generate the .htpasswd file: $ htpasswd -c /path/to/.htpasswd username-1 And to add additional users: $ htpasswd ...


1

VPN is your best option, because you dont have control over your ISP router, the issue must be on your server side network when goes to wan, if both host are Linux you can use OpenVPN here a Wiki of Open VPN on Debian: https://wiki.debian.org/OpenVPN


1

Most defiantly a VPN server or VPN Server Software on your home device or software tool like LetMeIn.. Since you do not have access to your ISP's Modem to do any kind of port forwarding. It really limits what you can do. If its just the data you need to access then maybe a cloud service like dropbox, onedrive etc. Then you can share the data you need. ...


1

Another option may be to use LLMNR (Link-Local Multicast Name Resolution) — see also Multicast DNS — so the user could go the device based on an identifier such as its serial number or some such.


1

I very strongly suspect that the problem is this line in the qemu host's iptables -t nat -L -n -v: 76 6384 MASQUERADE all -- * * 10.10.15.0/24 !10.10.15.0/24 This is causing original (ie, not return-half) traffic from hadoop2 to driver to be NATted to 10.10.15.1. You could test this hypothesis by exempting just the traffic ...


1

10.0.0.0/8 is a private address range, and as such will never be reachable from the outside. In your nmap, new.tooplas.com resolves to 10.0.1.15, and in another you have 68.179.41.131. So i'm guessing your network topology is as follows: Your LAN uses 10.0.0.0/8 internally Your default gateway (10.0.0.1) has a public IP 68.179.41.129 You have a range of ...



Only top voted, non community-wiki answers of a minimum length are eligible