Voiko roaming VPN -asiakas ylläpitää palvelua toimistolle?

Toimiston kannettava voi soittaa kotoa ja silti tarjota jotain, mitä toimisto tarvitsee, mutta vain kun kolme erillistä päätöstä osuu kohdalleen. Tunneli on kuljetus, sisäinen osoite on kohde ja käytäntö päättää, kuka saa koputtaa. Minkä tahansa näistä käsitteleminen koko vastauksena tuottaa tutun valituksen: isäntä vastaa pingiin, mutta sovellus ei koskaan yhdistä. Roolit eivät ole samat, ja ero on täsmälleen siinä, missä suunnittelutyö asuu.

Sisäänsoiton suunta ei kerro palvelun suunnasta mitään

Kun asiakas käynnistää tunnelin, se avaa polun, jota molemmat suunnat voivat käyttää, kun se on olemassa. Saako uusi yhteys tulla keskuksesta kyseiseen asiakkaaseen, on yhdyskäytävän käytäntökysymys, ei ominaisuus siitä, kuka soitti. Esimerkiksi reititetyssä OpenVPN-keskuksessa palvelin tarvitsee reitin asiakkaan sisäiseen osoitteeseen ja edelleenlähetyksen, joka sallii vertaissuhteen.

Kuvittele varastojärjestelmä, joka kyselee agenttia roaming-kannettavissa, tai kehittäjä, joka tarvitsee testi-API:n kotoa käsin työasemalta. Molemmat haluavat toimiston puolen aloittavan keskustelun, mikä on tavallisen asiakas-palvelin-kaavan vastakohta.

Isännöidyt etäkäyttötuotteet vaihtelevat tässä, eikä vaihtelu ole virhe. Jotkin hallinnoidut VPN-palvelut estävät tarkoituksella pyytämättömiä yhteyksiä yhdistettyihin asiakkaisiin, koska niiden malli on asiakkaasta resurssiin, ei resurssista asiakkaaseen. Lue tuotteen dokumentoitu arkkitehtuuri ennen kuin lupaat kollegalle, että hänen kannettavansa voi toimia palvelimena.

Seuraa paluupolkua ennen portin avaamista

Polussa on kolme osaa: yhdyskäytävän reitti, joka osoittaa asiakkaan sisäiseen osoitteeseen, käytäntö, joka sallii tietyn soittajan, ja kohdekohtainen kuunteleva palvelu. Jokainen osa epäonnistuu eri tavalla, siksi «VPN on pystyssä» ei kerro juuri mitään.

Hyvä uutinen on, että sisäinen polku ei tarvitse portin edelleenlähetystä asiakkaan kotireitittimessä. Juuri tästä on kyse palvelun julkaisemisessa tunnelin osoitteessa eikä kodin WAN-osoitteessa, jossa altistuminen ja NAT-säännöt olisivat täysin erilaiset. Kotireititin voi myös kieltäytyä hairpin-yhteydestä, joka saapuu toimistosta, joten WAN-reitti epäonnistuu syistä, joilla ei ole mitään tekemistä VPN:si kanssa. Liikenteen pitäminen tunnelin sisällä välttää molemmat ongelmat kerralla.

Tarkista myös kohdepuoli. Palvelu, joka on sidottu vain osoitteeseen 127.0.0.1, ei voi vastaanottaa tunnelin rajapinnalle saapuvaa yhteyttä, olivatpa yhdyskäytävän reitit kuinka oikeita tahansa. Isännän palomuurisääntö, joka sallii portin vain paikallisesta aliverkosta, pudottaa myös toimiston liikenteen, ja se sääntö on riippumaton yläpuolella olevasta VPN-käytännöstä.

Nimet ja osoitteet ovat suunnittelupäätöksiä

Tunnelin sisäinen osoite ei ole automaattisesti nimi. Hallitsemasi yksityinen DNS-tietue on selkeämpi kuin toivoa, että löytöprotokolla ylittää tunnelin, koska linkki-paikallinen multicast-nimiresoluutio pysyy paikallisessa segmentissä eikä muutu aliverkkojen väliseksi DNS:ksi.

Osoitteen vakaus on yhtä tärkeä. Jos VPN-asiakkaat ottavat osoitteita lyhyen vuokra-ajan altaasta, kannettavan sisäinen osoite vaihtuu istuntojen välillä ja jokainen siihen rakennettu kirjanmerkki, palomuurin laajuus ja valvontatarkistus hajoaa hiljaa. Käytä varausta tai dokumentoitua dynaamisen päivityksen polkua.

Sovi nimi sen kanssa, joka omistaa VPN-identiteetin, jotta tietue, osoitteen jako ja käyttöoikeuskäytäntö muuttuvat yhdessä eivätkä kolmessa eri tiketissä.

Testaa palvelua, älä jäsenyyttä

Vahvista kohteesta, mikä kuuntelee ja millä osoitteella, ja vahvista sitten yhdyskäytävän näkemys paluupolusta:

$ 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

Testaa nyt toimiston puolelta oikealla pyynnöllä kaiun sijaan. Onnistunut curl palvelua vastaan todistaa reitin, käytännön ja kuuntelijan kerralla, kun taas onnistunut ping todistaa vain, että ICMP on sallittu. Jos pyyntö epäonnistuu, etene taaksepäin kolmen osan kautta sen sijaan, että levität palomuuria ja toivot.

Saatavuus kuuluu samaan keskusteluun. Kannettava nukkuu, roaming-verkkojen välillä ja katkeaa päivän lopussa. Palvelu, jonka on vastattava milloin tahansa, kuuluu aina päällä olevaan isäntään, kun taas parhaan yrityksen palvelu voi jäädä asiakkaaseen, kun rajoitus on kirjattu.

Julkaise resurssi tarkoituksella, nimellä, sallittujen soittajien luettelolla ja omistajalla, niin etälaitteesta tulee tuettu palvelu eikä vahingossa syntynyt palvelin.