Miksi VPN-tunnelin osoite ei avaa saapuvaa porttia
Tunnelin osoite yksilöi asiakkaasi vertaisille, jotka voivat reitittää siihen, eikä koskaan luo kuuntelijaa. Tarkista sidonta, paluureitti ja sitten käytäntö.
Yhdistä toimiston VPN:ään, käynnistä pieni palvelu portissa 8443, lähetä tunnelin osoite kollegalle ja katso, miten yhteys epäonnistuu, vaikka asiakas ilmoittaa edelleen olevansa yhdistetty. Tunnelissa ei ole mitään rikki: osoite jaettiin, istunto on pystyssä, eikä vastauksen kuljettavia paketteja yksinkertaisesti koskaan päästetä läpi. Tee alla olevat kolme tarkistusta järjestyksessä ja pysähdy siihen, joka epäonnistuu, koska jokaisella on erilainen korjaus ja vain yksi niistä koskee VPN:ää.
Aloita siitä, mihin socket on todella sidottu
Ennen kuin mitään reititetään, jonkin on kuunneltava osoitteessa, johon kutsuja pääsee. Kehityspalvelimet ovat tavallinen syyllinen, koska monet niistä sitoutuvat oletuksena loopbackiin ja hyväksyvät vain yhteydet, jotka tulevat samalta koneelta. Tunnelin osoite ei muuta tätä sidontaa, ja käyttöjärjestelmä hylkää yhteyden kauan ennen kuin VPN on edes mukana.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lue paikallisen osoitteen sarake tilan sijaan. 127.0.0.1:8443 tarkoittaa vain loopbackia, ja korjaus on sidonta 0.0.0.0 tai itse tunnelin osoitteeseen. 0.0.0.0:8443 hyväksyy kaikilla liitäntöillä, mikä on laajempaa kuin useimmat tarkoittavat, kun koneella on myös julkinen osoite; 10.64.7.15:8443 on kapea versio, joka kuuntelee vain siellä, mihin kollega pääsee. Huomaa myös prosessin nimi samassa tulosteessa, sillä aiemmasta testistä jäänyt harhainen instanssi on tavallinen syy siihen, että portti näyttää avoimelta ja vastaa väärällä sisällöllä.
Kysy sitten, voiko mikään reitittää tuohon osoitteeseen
Tunnelin osoitteella on merkitystä vain vertaisille, jotka on määritetty lähettämään tämä etuliite tunneliin. Kollegan koneella on oma taulunsa, ja jos sillä ei ole reittiä tunnelin aliverkkoon, paketti menee oletusyhdyskäytävälle ja kuolee paikkaan, jolla ei ole aavistustakaan osoitteen olemassaolosta. Tämä on reitityskysymys kutsujan puolella, ei lupa sinun puolellasi.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Kahden asiakkaan välinen palvelin on yhtä tärkeä. Tavallisessa etäkäyttöratkaisussa jokainen asiakas avaa lähtevän yhteyden yhdyskäytävälle ja yhdyskäytävä pitää näiden virtojen tilan, joten vastaukset palaavat reittiä, jonka se jo tuntee. Yhteys asiakkaasta toiseen on uusi virta, joka yhdyskäytävän on hyväksyttävä ja välitettävä, ja monet käyttöönotot poistavat sen tarkoituksella käytöstä pitääkseen asiakkaat erillään toisistaan. Kuluttaja-VPN-palvelut eristävät yleensä oletuksena; yritysten yhdyskäytävät sallivat sen joskus ryhmittäin.
Tarkista suunta ennen kuin muutat mitään isännässä. Jos tunnelin osoite vastaa yhdyskäytävästä itsestään mutta ei vertaisesta, ero on yhdyskäytävän asiakas-asiakas-asetuksessa, eikä mikään paikallisen palomuurin muokkaus korvaa sitä.
Lopuksi etsi käytäntö, joka sallii virran
Reititetyn paketin ja vastaavan palvelun välissä on kolme käytäntökerrosta: VPN-palvelimen välityspäätös, isännän palomuuri ja mikä tahansa pilven suojausryhmä instanssin edessä. Kaikkien kolmen on oltava samaa mieltä, ja ne epäonnistuvat eri tavoin, minkä vuoksi yllä olevan taulukon oire on hyödyllisempi kuin selaimen virheilmoitus.
Isännän palomuuri on kerros, jonka ihmiset unohtavat onnistuneen sidonnan jälkeen, koska sääntö, joka sallii portin LAN-liitännällä, ei automaattisesti salli sitä tunneliliitännällä. Liitäntäkohtaiset säännöt ovat oikea suunnittelu ja samalla tavallinen syy palveluun, joka toimii toimistosta mutta ei kotoa. Lue säännön laajuus, älä sen porttinumeroa.
Tilallinen suodatus selittää päinvastaisen tapauksen. Kannettavastasi lähtevä yhteys luo tilan, ja sen vastaukset päästetään läpi ilman saapuvaa sääntöä. Kollegan yhteys on täysin uusi virta, jonka takana ei ole tilaa, joten se tarvitsee nimenomaisen luvan. Tämä epäsymmetria on koko syy siihen, miksi omalla koneellasi toimiva selainistunto ei kerro mitään siitä, onko palvelu tavoitettavissa ulkopuolelta.
Kun yksi tarkistus epäonnistuu, muuta suunnittelua äläkä tunnelia
Jos vaatimus on, että kollega avaa paikallisen palvelusi, rehellinen vastaus on yleensä saapuvaan käyttöön rakennettu mekanismi. Käänteinen SSH-tunneli on pienin: koneesi yhdistyy lähtevästi isäntään, johon kollega jo pääsee, ja kuuntelija on olemassa sillä isännällä.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Välityspalvelin tarvitsee GatewayPorts clientspecified -asetuksen SSH-palvelimensa kokoonpanossa, muuten välitetty kuuntelija sitoutuu välityspalvelimella loopbackiin ja kollega kohtaa saman hylkäyksen kuin ennen. Kaikelle, mikä kestää iltapäivää pidempään, kuormantasaaja tai ingress terveystarkistuksella ja julkaistun nimen varmenteella on parempi väline, ja sivustojen välinen tunneli molempien aliverkkojen reiteillä on oikea vastaus, kun kahden verkon todella täytyy puhua.
Jokainen näistä suunnitelmista tekee altistuksen selväksi, ja se on pointti. VPN siirtää paketteja verkkojen välillä, joihin sinulla oli jo valtuutus; se ei julkaise palvelua eikä muuta kannettavaa internetiin päin olevaksi isännäksi. Tehtävä on päättää, mitä kolmesta kerroksesta muutetaan, ja tunneli on niistä harvoin yksi.