VPN NATin takana, jota et voi määrittää: mikä silti toimii

Jokainen tunnelin päätepiste tarvitsee osoitteen ja portin, johon toinen puoli pääsee, ja reititin, jota et hallinnoi, on tavallinen syy siihen, että vaatimus epäonnistuu. Kiinnostavaa ei ole se, että kikkoja on, vaan se, että jokainen niistä riippuu sellaisen kartoituksen ominaisuudesta, jota et näe asiakkaasta käsin. Kaksi näistä ominaisuuksista ratkaisee lähes kaiken: miten kartoitus syntyy ja hyväksyykö se paketteja osoitteesta, johon sisäpuoli ei ole koskaan ottanut yhteyttä. Lajittele ympäristö näiden ominaisuuksien mukaan, niin kiertotiet lakkaavat olemasta kansanperinnettä.

Kartoitustaulu ratkaisee kaiken

Verkko-osoitteiden muunnos pitää taulua, jossa sisäinen osoite ja portti kirjataan julkista osoitetta ja porttia vastaan. Tietueeseen täsmäävät vastaukset muunnetaan takaisin, eikä ulkopuolelta saapuvalla paketilla, jolla ei ole täsmäävää tietuetta, ole lainkaan kohdetta. Tämä yksi käyttäytyminen selittää, miksi reitittimen takana oleva kuuntelija ei ole saavutettavissa internetistä. Se selittää myös, miksi kummankin suunnan ensimmäisen paketin on lähdettävä sisältä.

Katso taulua reitittimen puolelta, niin kiertotiet käyvät ilmeisiksi: joko jokin luo pysyvän tietueen, jokin luo tilapäisen ja pitää sen tuoreena, tai liikenne ei kulje sitä reittiä lainkaan. Artikkelin loppuosa on nuo kolme tapausta järjestyksessä. Mikään tässä ei riipu valmistajan ominaisuudesta sen yli, mitä taulu kirjaa.

Mitä kohtaamispalvelu voi ja mitä ei voi tehdä

UDP-reiänlyönti käyttää lähtevää tietuetta tilapäisenä avauksena sen sijaan, että voittaisi suodattimen. Molemmat osapuolet ottavat yhteyden kohtaamispalveluun, joka oppii kunkin julkisen päätepisteen ja ilmoittaa toiselle puolelle sen päätepisteen. Sitten molemmat lähettävät toisiaan kohti, ja jokainen lähtevä paketti luo tai virkistää tietueen, joka päästää vastauksen sisään. Järjestys saa sen toimimaan, ja järjestys tekee siitä myös hauraan: osapuoli, joka lähettää ennen kuin toinen puoli on luonut tietueensa, yksinkertaisesti pudotetaan, kun taas uusi yritys hetkeä myöhemmin onnistuu. Palvelu itse ei kanna VPN-liikennettä, joten sen ainoa vipu on ajoitus, jota se koordinoi.

Kartoituksen käyttäytyminen ratkaisee loput, ja RFC 4787 nimeää kolme muotoa: päätepisteestä riippumaton, osoitteesta riippuva sekä osoitteesta ja portista riippuva. Viimeisimmässä portti, jota osapuolen on tavoiteltava, vaihtuu jokaisen kohteen myötä, joten ennustaminen lakkaa olemasta luotettavaa. Siinä tekniikka kohtaa umpikujansa, koska operaattoritason NAT ja tiukka yrityspalomuuri poistavat molemmat sen ennustettavuuden, jota menetelmä tarvitsee, eikä mikään määrä uusia yrityksiä tuo sitä takaisin.

Keepalive-viestit, uudelleenkäynnistykset ja liikkuva päätepiste

Lävistetty polku on virtaus eikä kuuntelija, joten kaiken sen päällä ajettavan on kestettävä muutos. Sen on pidettävä kartoitus elossa säännöllisellä liikenteellä, huomattava julkisen päätepisteen siirtyminen ja perustettava yhteys uudelleen reitittimen uudelleenkäynnistyksen tai osoitteen uudelleenjaon jälkeen. Mesh-VPN-tuotteet panevat tämän logiikan omaan ohjaustasoonsa, kun taas tavallinen palvelin jättää sen sinulle. Keepalive auttaa vain niin kauan kuin sama kartoitus säilyy, ja se kuluttaa akkua mobiiliasiakkaassa, minkä vuoksi aggressiivinen väli ei ole ilmainen.

Tunnin nukkuva kannettava palaa yleensä eri julkiseen päätepisteeseen. Kaiken polun palauttavan on käynnistyttävä uudelleen sisältä, mikä palauttaa saman vaatimuksen asiakkaalle.

Kolme tapaa kiertää puuttuva portinohjaus

Ensimmäinen tapa pyytää reititintä luomaan tietueen itse, UPnP IGD:n, NAT-PMP:n tai PCP:n kautta, kun ominaisuus on olemassa ja päällä. Toinen antaa liikenteen releelle, jolla on julkinen osoite; se toimii aina ja maksaa aina kaistanleveyden lisäksi toisenlaisen luottamusrajan. Kolmas kääntää suunnan: sisäinen isäntä avaa lähtevän tunnelin julkiselle palvelimelle ja kaikki muu kulkee sen sisällä.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Releen päätepiste tekee tämän kaupan näkyväksi asiakkaan kokoonpanossa, jossa päätepiste on rele eikä osapuolen oma osoite. Pysyvä keepalive pitää kartoituksen lämpimänä, ja sallitut etuliitteet ratkaisevat, mitä asiakas saa lähettää sen yli. Käänteinen tunneli sisäisestä isännästä on sama ajatus toisella omistajalla, eikä se vaadi lainkaan NAT-muutosta. Jokainen kolmesta poistaa saapuvan vaatimuksen voittamatta palomuuria, joka estää pyytämättömän liikenteen suunnittelunsa mukaan, koska liikenne alkaa silti sisältä.

Sovita kiertotie reitittimen omistajaan

Jos hallinnoit reititintä, staattinen UDP-ohjaus on helpompi auditoida kuin mikään reiänlyöntimenetelmä ja se epäonnistuu tavalla, jonka näet. Jos et, ota selvää, tarjoaako valmistaja relettä tai isännöityä ohjaustasoa ja sallisiko käytäntö sen käytön. Jos kumpaakaan ei ole, jäljelle jäävät vaihtoehdot ovat käänteinen tunneli tai sen hyväksyminen, ettei päätepiste ole saavutettavissa ulkopuolelta. Sen kirjaaminen, mitä käytit, on tärkeämpää kuin miltä kuulostaa, koska vaihtoehdot eroavat siinä, kuka voi tarkkailla liikennettä ja mitä tapahtuu, kun kolmas osapuoli muuttaa jotain.

Huomaa, oliko polku, johon päädyit, suora vai releen kautta, sillä tämä yksi seikka ennustaa sekä viiveen että vikatilanteen käyttäytymisen. RFC 4787 on edelleen viite kaiken alla olevalle kartoituksen käyttäytymiselle, ja sen kartoitusta käsittelevän osan lukeminen on nopeampaa kuin kolmen kiertotien kokeileminen peräkkäin. Taulua ei kiinnosta, minkä vaihtoehdon valitsit; se kirjaa vain, mitä seuraava paketti saa tehdä.