I would like to connect to Google Cloud SQL from an external application using JDBC and the instance's IPv6 address as shown on my Google Developers Console (here obfuscated):
String url = "jdbc:mysql://abcd:abcd:abcd:abcd:abcd:abcd:abcd:abcd";
String user = "root";
String password = "<also_obfuscated>";
connection = DriverManager.getConnection(url, user, password);
This leads to the following exception:
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
Cannot load connection class because of underlying exception:
'java.lang.NumberFormatException:
For input string: "abcd:abcd:abcd:abcd:abcd:abcd:abcd:abcd"'.
I am using the latest JDBC driver for MySQL. Connection via JDBC and IPv4 works but requires an extra configuration step and incurs (small) extra cost.
So is it even possible to connect to MySQL via JDBC and IPv6 and if so how?
UPDATE According to the documentation, this URL should work for IPv6:
jdbc:mysql://address=(protocol=tcp)(host=abcd:abcd:abcd:abcd:abcd:abcd:abcd:abcd)(port=3306)
However, now I'm getting the following exception:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.
The driver has not received any packets from the server.
Besides the JDBC driver supporting IPv6 (which it does, according to the documentation), and the client OS supporting IPv6 (which mine should as it is OS X Yosemite), and the server OS supporting IPv6 (which the Google Cloud does because it reports an IPv6 server address) what other pieces need to be in place in order for IPv6 client-server connections to work?
E.g. does my ISP have to provide any particular support?
You need to register the IPV6 address from which you'll be coming into Google Cloud SQL, among the authorized addresses on the Cloud SQL console.
You can check that IPv6 address e.g by visiting sites such as whatismyv6.com .
Then, all your ISP has to do is to provide a stable IPV6 address (alas, even to these days, not all do -- alas, AT&T Uverse, my ISP at home, does not, for example).
Even from locations where I could reliably get a stable IPv6 address, I had exactly the same problem, originally -- until it dawned on me that, if I'm coming in with an IPv6 address and what I've authorized is an IPv4 one, Google Cloud SQL cannot "translate" one into the other to find out I'm in fact authorized!-)
Note that if you don't have and can't get an IPv6 address from which to connect (e.g. connecting from a home machine through an ISP that does not yet support IPv6) then you can hit the "Request IPv4 address" button under Google Developers Console / Storage / Cloud SQL / [Your Intance] / Access Control / IP Address and you will get one assigned (within a few seconds) which will cost $0.01 per hour, paid from your free $300 of credit if you still have that credit available. Once you move your app to, for example, one of Google's app servers, you will no doubt be able to get an IPv6 address. Release the IPv4 address when unused to save credit.
Try
String url = "jdbc:mysql://[abcd:abcd:abcd:abcd:abcd:abcd:abcd:abcd]";
In URLs literal IPv6 addresses have to be surrounded by [] so that the parser can see the difference between parts of the address and the optional port number which is also separated by a :.
It is often easier to use hostnames instead of literal IP addresses. It stays independent of the used IP protocol and changing addresses is easier as well.
Related
I have a Go service, deployed on Heroku, which pulls the IPv4 address from the request header successfully.
ip := net.ParseIP(strings.Split(r.Header.Get("X-Forwarded-For"), ",")[0]).String()
I have deployed the identical code as a service to Google Cloud, and the IP addresses are frequently IPv6 in about 25% of the time. After examining the full Request Header, there is no IPv4 address available anywhere, only IPv6.
Heroku's Request Header X-Forwarded-For ALWAYS contains the IPv4 address, yet Google Cloud doesn't. Does anyone know a way to force the IPv4 format for Request Headers in Google Cloud?
Clients can connect via IPv4 or IPv6 but not both. Only one address family will be used by the client and only one IP address will be recorded by the proxy.
Additional information:
Heroku does not support IPv6 so clients are forced to connect using IPv4. reference
If you only want IPv4 connections, do not enable the IPv6 frontends. However, I recommend using IPv6 where possible.
I was wondering if typing remote server url instead of typing localhost in spring boot properties db url (spring.datasource.url) is slower? Let's say I am running spring boot application on server with IPv4 123.123.12.12, will typing
jdbc:mariadb://123.123.12.12:3306/dbname
make it slower than
jdbc:mariadb://localhost:3306/dbname ?
When you access localhost, your /etc/hosts file will tell your computer not to look any further and redirects you to your own computer. When you access the IP address, your computer will ask the router to fetch the data, and your router will then point back to your computer.
Directly using the IP address of any interface on the localhost - either the loopback interface (127.0.0.1) or any other - is the option with the absolutely best performance. The packets will be actually routed through the loopback interface (no matter which IP is actually used) at - practically - CPU speed.
There are three reasons, however, to prefer 127.0.0.1 over the IPs of the other interfaces:
The loopback interface is crucial to the operation of the system and
as such it is initialized very early in the boot process and nearly
always available.
It is not affected by external factors: while removing the eth0 cable
will not by itself interrupt localhost's access to itself via eth0's
IP, it will mess things up if you have any of the many
"autoconfiguration" systems that will happily shutdown the interface
on link loss.
If you have a firewall setup, it's quite possible that the rule chain
is longer (and thus slightly worse performance-wise) when the IPs of
the public interfaces are involved.
Loopback, Also Refer This
Yes, setting up IP or DNS are slower than localhost. In case of localhost, application does not need to verify anything. It will directly try to connect the database on same server. But in case of IP and DNS, it first need to check that provided url is valid and then will connect to database.
When the No. of threads are 500 then following error is showing
failed: Connection timed out: connect, My IP is blocking due to multiple hits,
How can I provide 500 users load and My IP should not be blocked.
Well, you need to contact your ISP support and inform them that you're going to use your IP address for some performance testing and ask them to whitelist your IP in their DSoS attack protection software. If your ISP doesn't support this form of usage of your Internet channel - consider changing it or using a cloud VM service provider like Amazon EC2 or Microsoft Azure)
If might also be the case your system under test doesn't allow multiple connections from a single IP address due to aforementioned DDoS attack prevention mechanism on web server level, if this is the case you can use IP Spoofing technique in order to mimic various different IP addresses (not that the IPs or IP aliases must be present in the operating system). The IP address can be configured in the "Source address" section of the HTTP Request sampler
I'm wondering whether it's technically possible to detect IPv6 clients that are on my website?
I'm currently running Classic ASP using Request.ServerVariables("remote_addr") to detect my visitors IP addresses but some of my mobile users (which I think are Telstra customers here in Australia) are now using IPv6. This function only seems to give me an IPv4 address.
Is there an easy/free solution to detect IPv6 addresses of my visitors?
PS - I don't believe IPv6 is enabled on the server, so am I wasting my time?
Your website can only be reached over IPv6 if your webserver and ISP support it. When your server doesn't have IPv6 there is usually a translation mechanism in the user's ISP's network (NAT64) that translates the user's IPv6 packets to IPv4 packets that can reach your server. Because of that you will only see IPv4 connections coming in. Some of those will be real IPv4 users, some will be IPv6 users that got translated into IPv4.
If you want to be optimally reachable for all users then relying on someone else's translation mechanism is a hack that you'd want to avoid. Asking your ISP/hoster/sysadmin/etc to make your server reachable over IPv6 as well as over IPv4 is the best solution. That way all users can directly contact your server, no matter what their ISP offers.
If the clients are IPv6-only and do not have access to any transition mechanism they will never be able to reach your IPv4-only service in the first place.
In that case it will appear to those users as if your server is down and you will have no way of knowing they even tried reaching your server.
However IPv6-only clients with no access to a transition mechanism are still very rare. More likely the clients will have access to some transition mechanism such as NAT64.
There are a few ways to know if a client accessed your site through a NAT64.
The IPv4 address of the NAT64 may have information in reverse DNS or whois which will tell you that it is a NAT64 device. Additionally clients relying on NAT64 will often be unable to access literal IPv4 addresses. Only access through hostnames work as they rely on DNS64 to find the IPv6 address.
Another way of telling the difference is that the MSS value advertised in SYN packets tend to have different values for native IPv4 clients and NAT64 translated clients.
None of these are 100% reliable ways of telling the difference, but as long as the clients don't have any incentive to mess with your results they can provide a good estimate.
Notice that though the DNS64/NAT64 combo will allow IPv6-only clients to access IPv4-only servers it will not work with servers that have bad or misconfigured IPv6 access. So before you add an AAAA record on your domain make sure that the IPv6 address actually works. And once you have set up the AAAA record you can use a service such as https://nat64check.org/ to verify that it actually works.
Appreciate both responses above, it's made things significantly clearer for me.
After some further reading/investigation, it's apparent that IPv6 packets are being translated to IPv4 (or they are dual-stacking). If the former, I'm now trying to see if I can convert them at my end.
One example is this IPv6 address: 2001:8003:1909:2700:3c97:38e7:9c98:bb5b
It's being translated to IPv4 as: 101.177.229.36
There are many online calculators but none seem to give me the above conversion so I'm thinking their ISP is using their own translation mechanism.
I'm currently working on a ABAP Push Channel server to WebSocket client connection and I need the IP-address of the client in order to identify whether this client is the one I want to send the message to. In my scenario there could be multiple WebSocket connections.
Now there is the ssi_websocket_table table and the ssi_websocket_table_row row with the the field caller_ip, however this gives me the IP address of the DNS-Server of the network I'm connected to, and I expected the IP address of my local PC since the WebSocket-client is running on this machine.
Is there any other way to get the clients IP address from an active WebSocket connection in ABAP?
P.S. Looking at all the table entries, it shows the correct IP when using a different server configuration, as soon as I know why that's the case I will report back.
As pointed out by vwegert it makes no sense to use the IP to tell the WebSockets apart, I think it would probably be better to use an ID for each WebSocket connection instead.
You could get the IP from the WebSocket server context which gets the IP header apparently from the opening HTTP handshake for the connection:
DATA(lo_context) = i_context. " IF_APC_WSP_SERVER_CONTEXT type
DATA(lo_request) = lo_context->get_initial_request( ).
" initialize G_CONTEXT_ID_FIELD for PCP_SET_CONTEXT_FIELDS
DATA(lv_id) = lo_request->get_header_field( if_http_header_fields_sap=>remote_addr ).
the sample is taken from the SAP standard class CL_APC_WS_EXT_ABAP_ONLINE_COMM, ON_MESSAGE method.