As next-hop for #2 isn’t directly connected, #2 doesn’t make it into the routing table, and there’s nothing to redistribute into OSPF.
Like a black-hole route, #3 does end up in route table, but next-hop-interface on eth interface is bad practice. It will start ARP-ing for destinations that aren’t there. That’s why I suggested black-hole route. As soon as VPN client is up you will end up with more specific routes, so don’t be afraid wanted traffic will be blackholed.
Something like reverse route injection only comes handy when you share client address space with another VPN server. If there’s only one , I’d prefer static advertising the entire pool. This way, vpn clients connecting/disconnecting won’t affect routes all over the entire network.
If connected VPN clients end up in connected routes, redistribute connected (filtered), might do the reverse route injection