SSH tunnels don't work like that - the specifically forward tcp traffic on a set port to a specified address and port on the remote end of the tunnel. When you
ping you actually use a different protocol called
ICMP (Internet Control Message Protocol) on most systems (some use
udp) which will not be passed over your ssh tunnel.
For your specific needs you would probably be better off with a VPN to your home machine. Then you can redirect the traffic with routes to your local machine. This will then allow you to send any IP related protocols (including udp, tcp and icmp), so you can ping, browse and so forth.
This would be quite a task for large organisations like google, because for every host
you want to route to your home machine requires a route to be added to the server to handle this (and google has many IPs you will have to route). This is even the case for google if you were to route summarized netblocks of gooogle.
If you are willing to sacrifice your default route on your server (which would allow you to pass all non-local traffic over the VPN for routing), and use static routes on your server for any hosts on the server network then the task is much easier, because then it's just a case of IP forwarding. You point the default route to your VPN end point, and let IP forwarding on your home machine send the traffic out to the internet.
If you only want to redirect web traffic (HTTP/HTTPS) then you could use a reverse ssh tunnel in conjunction with a web proxy. This is fairly trivial as web clients provide an easy mechanism to point at the proxy.
You could also attempt to set up a SOCKS proxy (which is similar to a web proxy, but supports some other applications/protocols), but then only the applications on the server that utilize SOCKS could make use of it.