There are good reasons for constructing the base class interface with all virtual functions as private or protected (see this). But then how does one prevent the derived cla
Access control in C++ possibly doesn't do what you want. It's not intended to enforce DRM-style constraints to stop you sharing your access. If A has access to B, then A can call B and use the result for any purpose, including returning it to another caller who doesn't have access to B.
The problem that's discussed in the article you link to isn't about A deliberately or maliciously sharing B. It's about what happens if you put a public virtual function in a published interface, and later try to change the class so that it uses their suggested Template Method patterns, including private virtual functions. Child classes have written public overrides of the virtual function, so you can no longer separate the two concerns (access and virtual-ness) without modifying all the child classes. The way I read it, the article does provide a solution to the problem it presents, and that solution is "never make virtual functions public in the first place".
Virtual functions should be treated very much like data members — make them private, until design needs indicate a less restricted approach is indicated. It is much easier to promote them to a more accessible level, than it is to demote them to a more private level.
The reason this doesn't solve your problem, is that they didn't consider your problem.