A mundet një klient VPN nomad të strehojë një shërbim për zyrën?

Laptopi i zyrës mund të lidhet nga shtëpia dhe prapë të ofrojë diçka që zyra ka nevojë, por vetëm kur tre vendime të ndara përputhen. Tuneli është transport, adresa e brendshme është destinacioni, dhe politika vendos kush mund të trokasë. Trajtimi i secilit prej tyre si përgjigja e plotë prodhon ankesën e njohur: hosti përgjigjet ndaj ping-ut por aplikacioni nuk lidhet kurrë. Rolet nuk janë të njëjta, dhe dallimi është pikërisht aty ku qëndron puna e projektimit.

Drejtimi i lidhjes nuk thotë asgjë për drejtimin e shërbimit

Kur një klient nis një tunel, ai hap një rrugë që të dy drejtimet mund ta përdorin pasi ekziston. Nëse një lidhje e re mund të hyjë nga qendra drejt atij klienti është çështje e politikës së portës, jo veti e atij që u lidh. Për shembull, në një qendër OpenVPN të rrugëzuar, serveri ka nevojë për një rrugë drejt adresës së brendshme të klientit dhe për përcjellje që lejon marrëdhënien e barabartë.

Përfytyroni një sistem inventari që anketon një agjent në laptopë nomadë, ose një zhvillues që ka nevojë për një API testimi nga një stacion pune në shtëpi. Të dy duan që ana e zyrës ta nisë bisedën, gjë që është e kundërta e modelit të zakonshëm klient-ndaj-server.

Produktet e aksesit në distancë të strehuara ndryshojnë këtu, dhe ky ndryshim nuk është defekt. Disa VPN të menaxhuara bllokojnë qëllimisht lidhjet e pa kërkuara drejt klientëve të lidhur, sepse modeli i tyre është klient-ndaj-burimit, jo burim-ndaj-klientit. Lexoni arkitekturën e dokumentuar të produktit përpara se t'i premtoni një kolegu se laptopi i tij mund të veprojë si server.

Ndiqni rrugën e kthimit para se të hapni një portë

Rruga ka tre pjesë: një rrugë në portë që tregon drejt adresës së brendshme të klientit, një politikë që lejon thirrësin konkret, dhe një shërbim që dëgjon në objektiv. Secila pjesë dështon ndryshe, prandaj «VPN-ja është ndezur» nuk thotë pothuajse asgjë.

Lajmi i mirë është se rruga e brendshme nuk ka nevojë për përcjellje porti në ruterin e shtëpisë së klientit. Ky është kuptimi i publikimit të shërbimit në adresën e tunelit në vend të adresës WAN të shtëpisë, ku ekspozimi dhe rregullat NAT do të ishin krejt të ndryshme. Një ruter shtëpiak mund të refuzojë gjithashtu të bëjë hairpin të një lidhjeje që vjen nga zyra, kështu që rruga WAN dështon për arsye të palidhura me VPN-në tuaj. Mbajtja e trafikut brenda tunelit shmang të dy problemet njëherësh.

Kontrolloni edhe anën e objektivit. Një shërbim i lidhur vetëm me 127.0.0.1 nuk mund të pranojë një lidhje që vjen në ndërfaqen e tunelit, sado të sakta të jenë rrugët e portës. Një rregull firewalls i hostit që lejon portën vetëm nga nënrrjeti lokal do të hedhë poshtë edhe trafikun e zyrës, dhe ai rregull është i pavarur nga politika e VPN-së mbi të.

Emrat dhe adresat janë vendime projektimi

Një adresë brenda tunelit nuk është automatikisht emër. Një regjistrim DNS privat që ju kontrolloni është më i qartë sesa shpresa se një protokoll zbulimi do të kalojë tunelin, sepse zgjidhja e emrave me multicast lokal mbetet në segmentin lokal dhe nuk bëhet DNS midis nënrrjeteve.

Stabiliteti i adresës ka po aq rëndësi. Nëse klientët VPN marrin nga një pishinë me qira të shkurtra, adresa e brendshme e laptopit ndryshon midis seancave dhe çdo faqerojtës, shtrirje firewalls dhe kontroll monitorimi i ndërtuar mbi të thyhet në heshtje. Përdorni një rezervim ose një rrugë të dokumentuar përditësimi dinamik.

Bien dakord për emrin me atë që zotëron identitetin e VPN-së, në mënyrë që regjistrimi, caktimi i adresës dhe politika e aksesit të ndryshojnë së bashku dhe jo në tre bileta të ndara.

Provoni shërbimin, jo anëtarësimin

Nga objektivi, konfirmoni çfarë dëgjon dhe në çfarë adrese, pastaj konfirmoni pikëpamjen e portës për rrugën e kthimit:

$ 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

Tani provoni nga ana e zyrës me një kërkesë të vërtetë në vend të një jehone. Një curl i suksesshëm ndaj shërbimit provon rrugën, politikën dhe dëgjuesin njëherësh, ndërsa një ping i suksesshëm provon vetëm se ICMP lejohet. Nëse kërkesa dështon, kthehuni mbrapsht nëpër tre pjesët në vend që të zgjeroni firewalin dhe të shpresoni.

Disponueshmëria i përket të njëjtit bisedë. Një laptop fle, nomadizon midis rrjeteve dhe shkëputet në fund të ditës. Një shërbim që duhet të përgjigjet në çdo orë i përket një hosti gjithmonë të ndezur, ndërsa një shërbim me përpjekje më të mirë mund të mbetet në klient me atë kufizim të shkruar.

Publikoje burimin me qëllim, me një emër, një listë thirrësish të lejuar dhe një pronar, dhe pajisja në distancë bëhet një shërbim i mbështetur në vend të një serveri aksidental.