In order to protect from a man-in-the-middle attack, at least one of the endpoints of the communication needs to have some prior knowledge about the other endpoint. It's usually up to the client to verify that it's talking to the right server, because servers tend to allow potentially any client to connect to them. The general term for the kind of infrastructure that provides this prior knowledge is a public-key infrastructure.
In the case of HTTPS, the prior knowledge normally comes with the intermediate step of a certificate authority. A web browser contains a predefined list of CA with their public keys, and accepts a website as genuine if it can demonstrate that its public key has been signed by the private key a CA.
In the case of SSH, the prior knowledge normally comes from having contacted the server previously: the client records the server's public key and refuses to proceed if the server's public key is not the recorded one. (This also exists for HTTPS with certificate pinning.) On the first connection, it's up to the SSH user to verify the public key.
There is no standard followed by VPN software. You need to read the documentation of your VPN software. In enterprise deployments, it is common to either deploy the server certificate to employees' computers alongside the VPN software, or require the employee to make a first connection to the VPN from inside the company network where a MITM attack is not feared. The certificate is then stored in the VPN software configuration and the VPN client will refuse to connect if the server's public key changes.
If you're deploying a VPN service for your own use or for your organization's use, you should take care of provisioning the server certificate at installation time, before you go out in the wild. If a secure network is not available, you'll need to rely on some other communication channel to send the certificate. It could be an email, if that's how you identify users, but it would be best to rely on a pre-existing infrastructure such as GPG keys (send the certificate in a signed email) — which of course only shifts the problem to how to verify the GPG key.
If you're using a cloud-based VPN service, that service should provide you a way to verify their certificate (e.g. a web page served over HTTPS) and should document how to install the certificate or how to verify it on first use. Again, there isn't a single process that all VPN software follow.