SoftEther VPN Azure: en reläväg, inte en öppen port

Din server står bakom en router som du inte kan konfigurera, så den uppenbara planen att vidarebefordra en port är inte tillgänglig. VPN Azure finns just för den situationen, och löser den genom att vända riktningen på den första anslutningen: servern ringer ut till en relä, och klienterna når reläet i stället för servern. Att förstå den vändningen förklarar både vad tjänsten åtgärdar och varje gräns du senare stöter på.

Vad som ändras på vägen

Med en vanlig lyssnare öppnar en klient en TCP-anslutning till en offentlig adress som din router vidarebefordrar till servern. Med reläet upprätthåller servern en utgående anslutning till reläinfrastrukturen, och reläet tar emot klientanslutningar och skickar deras nyttolast vidare till den väntande servern. Ingen inkommande port öppnas, ingen statisk adress krävs, och routern förblir orörd. Från brandväggens synvinkel är servern en vanlig utgående klient, och det är därför restriktiva nätverk tillåter den.

Reläet tilldelar den servern ett namn på sin egen domän, och klienter konfigureras att ansluta dit.

Det namnet tillhör relätjänsten, som inte är en Microsoft Azure VPN Gateway även om båda kallas Azure något. Att behandla dem som utbytbara ger en konfiguration som inte kan fungera.

Vilka protokoll som överlever reläet

Reläet transporterar SoftEther-protokollet, och projektet dokumenterar SSTP som klientalternativ, vilket är användbart eftersom Windows levererar en SSTP-klient. Det blir dock inte en generell bärare för varje lyssnare på värden: en OpenVPN-lyssnare, en IPsec-svarare och en L2TP-tjänst behöver var sin egen nåbara ändpunkt, och ingen av dem transporteras genom reläet bara för att SoftEther-servern är ansluten.

Klientprofiler pekar därför på relänamnet i stället för serveradressen, och en befintlig profil byggd för en direkt anslutning fungerar inte oförändrad. Kontrollera listan över klienter som stöds för den version du kör innan du designar kring ett protokoll som reläet inte bär.

Vad reläet inte gör åt dig

Reläet är en transport. Det skapar inga användare, virtuella hubbar, åtkomstprinciper eller rutter, och det vet ingenting om de privata nätverken bakom din server. Om fjärrklienter måste nå ett LAN-undernät behöver servern fortfarande brygg- eller routingkonfigurationen, returvägen och brandväggsprincipen som får det att fungera. Överlappande adressplaner i båda ändar är också osynliga för reläet och förblir ditt problem att lösa.

De säkerhetsinställningar som stöds väljer du också själv. Projektdokumentationen innehåller exempel på äldre plattformar, och att kopiera föråldrade chiffer- eller certifikatinställningar från en gammal skärmbild är ett bra sätt att bygga en tunnel som ingen kan granska. Använd aktuell vägledning för den version du kör.

Certifikatvalidering och användarautentisering förblir serverns ansvar, och reläet ersätter aldrig något av dem.

Driv det som ett beroende

Tillgängligheten omfattar nu en tredje part. När reläet inte går att nå kan klienterna inte ansluta oavsett hur frisk din server är, och felet ser ut som ett klientproblem utifrån. Övervaka relävägen separat från serverns egen hälsa, och håll en dokumenterad reservväg som en direkt lyssnare på en annan adress redo för den dag det spelar roll.

Latensen följer reläets geografi i stället för dina användares närhet, vilket är värt att mäta innan du lovar interaktiv prestanda över det.

Verifiera serverns identitet och sedan en verklig applikationsväg, inte bara en lyckad anslutningsbanner, och kontrollera om resursen du behöver går att nå över den adressfamilj reläet bär. Anteckna relänamnet, protokollet som används och reservvägen, eftersom de tre fakta besvarar de flesta framtida frågor om den här länken.