Gazdagépként szolgálhat egy vándorló VPN-kliens az iroda számára?

Az irodai laptopod bejelentkezhet otthonról, és mégis nyújthat valamit, amire az irodának szüksége van, de csak akkor, ha három külön döntés összeér. Az alagút a szállítás, a belső cím a cél, és a szabályzat dönti el, ki kopogtathat. Ha bármelyiket a teljes válaszként kezeled, megjelenik az ismerős panasz: a gazdagép válaszol a pingekre, de az alkalmazás soha nem csatlakozik. A szerepek nem ugyanazok, és a különbség pontosan ott van, ahol a tervezési munka él.

A becsatlakozás iránya semmit sem mond a szolgáltatás irányáról

Amikor egy kliens alagutat indít, olyan útvonalat nyit, amelyet létrejötte után mindkét irány használhat. Az, hogy egy új kapcsolat beléphet-e a központból az adott kliens felé, átjárószabályzat kérdése, nem annak tulajdonsága, aki becsatlakozott. Egy irányított OpenVPN központban például a kiszolgálónak útvonalra van szüksége a kliens belső címéhez, valamint továbbításra, amely engedi a peer kapcsolatot.

Képzelj el egy leltárrendszert, amely vándorló laptopokon lévő ügynököt kérdez le, vagy egy fejlesztőt, akinek teszt API kell otthoni munkaállomásról. Mindkettő azt akarja, hogy az irodai oldal kezdje a beszélgetést, ami a szokásos kliens-szerver minta fordítottja.

A hosztolt távoli hozzáférési termékek ebben különböznek, és a különbség nem hiba. Egyes felügyelt VPN-szolgáltatások szándékosan blokkolják a csatlakozott kliensek felé irányuló kéretlen kapcsolatokat, mert modelljük kliensből erőforrásba, nem erőforrásból kliensbe mutat. Olvasd el a termék dokumentált architektúráját, mielőtt megígéred egy kollégának, hogy a laptopja kiszolgálóként működhet.

Kövesd a visszaút irányát, mielőtt portot nyitnál

Az útvonalnak három része van: egy útvonal az átjárón, amely a kliens belső címére mutat, egy szabályzat, amely engedi az adott hívót, és egy figyelő szolgáltatás a célon. Mindegyik rész másként hibázik, ezért a „a VPN fut” szinte semmit sem mond.

A jó hír, hogy a belső útvonalhoz nincs szükség porttovábbításra a kliens otthoni routerén. Pontosan erről szól, hogy a szolgáltatást az alagút címén tesszük közzé, nem az otthoni WAN címen, ahol a kitettség és a NAT-szabályok egészen mások lennének. Az otthoni router meg is tagadhatja az irodából érkező kapcsolat hairpinelését, így a WAN-útvonal a VPN-től független okokból hibázik. A forgalom alagúton belül tartása egyszerre kerüli el mindkét problémát.

Ellenőrizd a cél oldalát is. A csak 127.0.0.1-hez kötött szolgáltatás nem tudja fogadni az alagút interfészén érkező kapcsolatot, bármilyen helyesek is az átjáró útvonalai. Az a gazdagép tűzfalszabály, amely a portot csak a helyi alhálózatból engedi, szintén eldobja az irodai forgalmat, és ez a szabály független a felette lévő VPN-szabályzattól.

A nevek és a címek tervezési döntések

Az alagúton belüli cím nem automatikusan név. Az általad kontrollált privát DNS-rekord világosabb, mint abban bízni, hogy egy felderítő protokoll átkel az alagúton, mert a link-local multicast névfeloldás a helyi szegmensen marad, és nem lesz alhálózatok közötti DNS.

A cím stabilitása ugyanolyan fontos. Ha a VPN-kliensek rövid bérletű készletből kapnak címet, a laptop belső címe munkamenetek között változik, és minden rá épülő könyvjelző, tűzfalhatókör és monitorozási ellenőrzés csendben eltörik. Használj foglalást vagy dokumentált dinamikus frissítési útvonalat.

Egyeztesd a nevet azzal, aki a VPN-identitás tulajdonosa, hogy a rekord, a címkiosztás és a hozzáférési szabályzat együtt változzon, ne három külön jegyben.

A szolgáltatást teszteld, ne a tagságot

A célról igazold, mi figyel és melyik címen, majd igazold az átjáró nézetét a visszaútról:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Most tesztelj az irodai oldalról valódi kéréssel, ne visszhanggal. Egy sikeres curl a szolgáltatás ellen egyszerre bizonyítja az útvonalat, a szabályzatot és a figyelőt, míg egy sikeres ping csak azt bizonyítja, hogy az ICMP engedélyezett. Ha a kérés meghiúsul, menj visszafelé a három részen, ahelyett hogy szélesítenéd a tűzfalat és reménykednél.

Az elérhetőség ugyanabba a beszélgetésbe tartozik. A laptop alszik, hálózatok között vándorol, és a nap végén lecsatlakozik. A szolgáltatásnak, amelynek bármely órában válaszolnia kell, mindig bekapcsolt gazdagépen a helye, míg a legjobb erőfeszítésű szolgáltatás maradhat a kliensen, ha ezt a korlátot leírjuk.

Tedd közzé az erőforrást szándékosan, névvel, engedélyezett hívók listájával és tulajdonossal, és a távoli eszköz támogatott szolgáltatássá válik, nem véletlen kiszolgálóvá.