SoftEther VPN Azure: een relaypad, geen open poort
VPN Azure is een relay waar de server zelf naartoe belt, geen port-forwarding. Het helpt achter NAT, draagt slechts enkele protocollen en voegt een afhankelijkheid toe die je moet monitoren.
Je server staat achter een router die je niet kunt configureren, dus het voor de hand liggende plan om een poort door te sturen is niet beschikbaar. VPN Azure bestaat precies voor die situatie, en lost het op door de richting van de eerste verbinding om te keren: de server belt uit naar een relay, en clients bereiken de relay in plaats van de server. Die omkering begrijpen verklaart zowel wat de dienst oplost als elke grens die je later tegenkomt.
Wat er in het pad verandert
Met een gewone listener opent een client een TCP-verbinding naar een openbaar adres dat je router naar de server doorstuurt. Met de relay onderhoudt de server een uitgaande verbinding naar de relay-infrastructuur, en de relay accepteert clientverbindingen en geeft hun payload door aan de wachtende server. Er wordt geen inkomende poort geopend, er is geen statisch adres nodig, en de router blijft onaangeroerd. Vanuit het perspectief van de firewall is de server een gewone uitgaande client, en daarom staan beperkende netwerken hem toe.
De relay kent die server een naam op zijn eigen domein toe, en clients worden geconfigureerd om daar verbinding mee te maken.
Die naam is eigendom van de relaydienst, die geen Microsoft Azure VPN Gateway is ook al heten beide Azure iets. Ze als uitwisselbaar behandelen levert een configuratie op die niet kan werken.
Welke protocollen de relay overleven
De relay transporteert het SoftEther-protocol, en het project documenteert SSTP als clientoptie, wat handig is omdat Windows een SSTP-client meelevert. Het wordt echter geen algemene drager voor elke listener op de host: een OpenVPN-listener, een IPsec-responder en een L2TP-dienst hebben elk hun eigen bereikbare eindpunt nodig, en geen van hen wordt door de relay getransporteerd alleen omdat de SoftEther-server verbonden is.
Clientprofielen wijzen daarom naar de relaynaam in plaats van het serveradres, en een bestaand profiel voor een directe verbinding werkt niet ongewijzigd. Controleer de lijst met ondersteunde clients voor de versie die je draait voordat je ontwerpt rond een protocol dat de relay niet draagt.
Wat de relay niet voor je doet
De relay is een transport. Hij maakt geen gebruikers, virtuele hubs, toegangsbeleid of routes aan, en weet niets van de private netwerken achter je server. Als externe clients een LAN-subnet moeten bereiken, heeft de server nog steeds de bridge- of routingconfiguratie, het retourpad en het firewallbeleid nodig die dat mogelijk maken. Overlappende adresplannen aan beide kanten zijn ook onzichtbaar voor de relay en blijven jouw probleem om op te lossen.
De ondersteunde beveiligingsinstellingen kies je ook zelf. De projectdocumentatie bevat voorbeelden van oudere platforms, en verouderde cipher- of certificaatinstellingen uit een oude schermafbeelding kopiëren is een goede manier om een tunnel te bouwen die niemand kan auditen. Gebruik de actuele richtlijnen voor de versie die je draait.
Certificaatvalidatie en gebruikersauthenticatie blijven de verantwoordelijkheid van de server, en de relay vervangt nooit een van beide.
Beheer het als een afhankelijkheid
De beschikbaarheid omvat nu een derde partij. Wanneer de relay onbereikbaar is, kunnen clients niet verbinden ongeacht hoe gezond je server is, en de storing ziet er van buiten uit als een clientprobleem. Monitor het relaypad apart van de gezondheid van de server, en houd een gedocumenteerde terugvaloptie zoals een directe listener op een ander adres achter de hand voor de dag dat het ertoe doet.
De latentie volgt de geografie van de relay in plaats van de nabijheid van je gebruikers, wat het meten waard is voordat je interactieve prestaties erover belooft.
Verifieer de identiteit van de server en daarna een echt applicatiepad, niet alleen een succesvolle verbindingsbanner, en controleer of de resource die je nodig hebt bereikbaar is via de adresfamilie die de relay draagt. Noteer de relaynaam, het gebruikte protocol en de terugvaloptie, want die drie feiten beantwoorden de meeste toekomstige vragen over deze verbinding.