SoftEther VPN Azure: putanja preko releja, a ne otvoreni port

Vaš poslužitelj stoji iza usmjerivača koji ne možete konfigurirati, pa očigledan plan prosljeđivanja porta nije dostupan. VPN Azure postoji upravo za tu situaciju i rješava je okretanjem smjera prve veze: poslužitelj se spaja prema van na relej, a klijenti dolaze do releja umjesto do poslužitelja. Razumijevanje tog okretanja objašnjava i što usluga ispravlja i svako ograničenje na koje ćete kasnije naići.

Što se mijenja na putanji

Uz uobičajeni slušatelj, klijent otvara TCP vezu prema javnoj adresi koju vaš usmjerivač prosljeđuje poslužitelju. Uz relej, poslužitelj održava izlaznu vezu prema infrastrukturi releja, a relej prihvaća klijentske veze i predaje njihov teret poslužitelju koji čeka. Nijedan ulazni port se ne otvara, statična adresa nije potrebna i usmjerivač ostaje netaknut. Iz kuta vatrozida poslužitelj je običan izlazni klijent, zbog čega ga restriktivne mreže dopuštaju.

Relej dodjeljuje tom poslužitelju ime na vlastitoj domeni i klijenti se konfiguriraju da se spajaju tamo.

To ime pripada usluzi releja, koja nije Microsoft Azure VPN Gateway iako se obje zovu Azure nešto. Tretiranje kao zamjenjivih daje konfiguraciju koja ne može raditi.

Koji protokoli preživljavaju relej

Relej prenosi protokol SoftEther, a projekt dokumentira SSTP kao klijentsku opciju, što je korisno jer Windows dolazi sa SSTP klijentom. Ipak, ne postaje opći nosač za svakog slušatelja na hostu: slušatelj OpenVPN, odgovarač IPsec i usluga L2TP trebaju svaki svoju dostupnu krajnju točku i nijedan se ne prenosi preko releja samo zato što je poslužitelj SoftEther povezan.

Zato klijentski profili pokazuju na ime releja, a ne na adresu poslužitelja, i postojeći profil izgrađen za izravnu vezu neće raditi bez izmjena. Prije nego što projektirate oko protokola koji relej ne prenosi, provjerite popis podržanih klijenata za verziju koju pokrećete.

Što relej ne radi za vas

Relej je transport. Ne stvara korisnike, virtualne čvorove, politike pristupa ni rute i ne zna ništa o privatnim mrežama iza vašeg poslužitelja. Ako udaljeni klijenti moraju dosegnuti LAN podmrežu, poslužitelju je i dalje potrebna konfiguracija mosta ili usmjeravanja, povratna putanja i politika vatrozida koje to omogućuju. Preklapajući planovi adresa na oba kraja također su nevidljivi releju i ostaju vaš problem za rješavanje.

Podržane sigurnosne postavke također birate sami. Dokumentacija projekta sadrži primjere starijih platformi, a kopiranje zastarjelih postavki šifriranja ili certifikata sa stare snimke zaslona dobar je način da izgradite tunel koji nitko ne može revidirati. Koristite aktualne smjernice za verziju koju pokrećete.

Validacija certifikata i autentifikacija korisnika ostaju odgovornost poslužitelja i relej nikada ne zamjenjuje ni jedno od toga.

Upravljajte njime kao ovisnošću

Dostupnost sada uključuje treću stranu. Kada relej nije dostupan, klijenti se ne mogu povezati bez obzira na to koliko je vaš poslužitelj zdrav, a kvar izvana izgleda kao problem klijenta. Nadzirite putanju preko releja odvojeno od zdravlja poslužitelja i držite dokumentiran rezervni plan, poput izravnog slušatelja na drugoj adresi, za dan kada to bude važno.

Kašnjenje slijedi geografiju releja, a ne blizinu vaših korisnika, što vrijedi izmjeriti prije nego što obećate interaktivne performanse preko njega.

Provjerite identitet poslužitelja, a zatim stvarnu aplikacijsku putanju, ne samo uspješan banner veze, i provjerite je li resurs koji vam treba dostupan preko obitelji adresa koju relej prenosi. Zapišite ime releja, korišteni protokol i rezervni plan, jer te tri činjenice odgovaraju na većinu budućih pitanja o ovoj vezi.