Hi and welcome to network engineering.
That's what web filtering proxy servers (transparent or explicit) are for. As such they are bordering to be off-topic here. And ressource recommendations are off-topic, too.
Yet sometimes, such proxies (especially in their "transparent" variety) are embedded in the software running on "next generation firewalling" product ranges, on hardware boxes or virtual appliances offered by some vendors.
What they do is this: These boxes fake the initial (TCP) session setup, impersonating the server to the client, and they wait for the client to issue the application layer request, typically a HTTP GET or the start of an SSL/TLS negotiation for HTTPS. At the same time, on their "outside interface", they impersonate the client and start talking to the "real" server on the internet. Then this initial traffic is closely inspected.
They look at headers from the HTTP request (such as the HTTP Host header or the GET request) or they inspect the SSL/TLS dialog (such as the ServerNameIndication from the client or the CN or SAN's from the certificate the server presents).
Then, they match this information against their filtering mechanism (e.g. a local database, or a an online lookup in the database of the given vendor), and process or block the request accordingly.
One step further, these boxes can not only look at HTTP or the not-yet-ecrypted part of SSL/TLS, but sometimes, they even generate an SSL/TLS certificate ad-hoc (using an internal CA of their own) and present it to the client.
If the client (by configuration or trickery) happens to trust a certificate for "my.bank.com" which is signed by "ourwebfilterproxy.company.com", then SSL/TLS session is established, the client issues its http request and the webfiltering box can look at the encrypted content. Yes, that's what others call a man-in-the-middle attack.
In this context, a VPN (which variety? MPLS L3-VPN? Multipoint L2 VPN? Remote Access VPN? Site to Site VPN?) is only one of many options to get the traffic-of-interest to flow through such a "next generation firewall", if that box or VM is not hosted on your premises.
Seen from a distance, your primary filtering criterion is probably the web site's domain name in the URL. Therefore, you might want to consider tackling the problem from that side: There are ways to accomplish a large subset of such "web" filtering by doing DNS filtering, by offering a restrictive DNS service and by preventing client systems from using alternative DNS servers --- but now we're getting off-topic, definitely.