Zergatik zure VPN tunelaren helbideak ez du sarrera ataka bat irekitzen
Tunel helbide batek zure bezeroa bertara bideratu dezaketen pareen aurrean identifikatzen du, eta ez du inoiz entzulerik sortzen. Egiaztatu lotura, itzulera-bidea, gero politika.
Konektatu bulegoko VPNra, abiarazi zerbitzu txiki bat 8443 atakan, bidali tunelaren helbidea lankide bati eta ikusi konexioak huts egiten duela bezeroak oraindik konektatuta dagoela dioen bitartean. Tunelean ez dago ezer hautsirik: helbidea eman da, saioa martxan dago eta erantzuna eramango zuten paketeak ez dira inoiz onartzen. Egin beheko hiru egiaztapenak hurrenez hurren eta gelditu huts egiten duenean, bakoitzak konponbide desberdina baitu eta horietako bakarra delako VPNari buruzkoa.
Hasi socket-a benetan non lotuta dagoen tokitik
Ezer bideratu aurretik, zerbait entzuten egon behar da deitzaileak irits dezakeen helbide batean. Garapen-zerbitzariak dira errudun ohikoa, asko lehenespenez loopback-era lotzen baitira eta makina berean sortutako konexioak soilik onartzen dituzte. Tunel helbide batek ez du lotura hori aldatzen, eta sistema eragileak konexioa ukatuko du VPNa inplikatu baino askoz lehenago.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Irakurri helbide lokalaren zutabea, ez egoera. 127.0.0.1:8443 loopback soilik esan nahi du, eta konponbidea 0.0.0.0 edo tunelaren helbideari berari lotzea da. 0.0.0.0:8443 interfaze guztietan onartzen du, eta hori zabalagoa da jendeak uste duena makina batek helbide publikoa ere duenean; 10.64.7.15:8443 lankideak irits dezakeen tokian soilik entzuten duen bertsio estua da. Begiratu prozesuaren izena irteera berean, proba zahar bateko instantzia bat galduta egotea ohikoa baita ataka irekita ematen duelako eta eduki okerrarekin erantzuten duelako.
Gero galdetu ea ezerk helbide horretara bideratu dezakeen
Tunel helbide batek zentzua du soilik prefijo hori tunelera bidaltzeko konfiguratuta dauden pareentzat. Lankidearen makinak bere taula propioa du, eta tuneleko azpisarearen biderik ez badu, paketea lehenespenezko atebidera joaten da eta helbidea existitzen denik ez dakin leku batean hiltzen da. Hau deitzailearen aldeko bideratze kontua da, ez zure aldeko baimena.
| 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 |
Bi bezeroen arteko zerbitzariak berdin axola du. Urruneko sarbidearen ohiko diseinuan bezero bakoitzak irteerako konexio bat irekitzen du atebidera eta atebideak fluxu horien egoera gordetzen du, beraz erantzunak jada ezagutzen duen bide batetik itzultzen dira. Bezero batetik besterako konexioa atebideak onartu eta birbidali behar duen fluxu berria da, eta inplementazio askok nahita desaktibatzen dute bezeroak elkarrengandik isolatuta edukitzeko. Kontsumo VPN zerbitzuek normalean lehenespenez isolatzen dute; enpresa atebideek batzuetan taldeka baimentzen dute.
Egiaztatu noranzkoa hostean ezer aldatu aurretik. Tunel helbideak atebidearen beretik erantzuten badu baina pare batetik ez, atebidearen bezero-tik-bezerora ezarpena da aldea, eta tokiko suebakiko edozein aldaketak ezin du hori ordezkatu.
Azkenik, fluxua baimentzen duen politika aurkitu
Hiru politika geruza daude bideratutako pakete baten eta erantzuten duen zerbitzu baten artean: VPN zerbitzariaren birbidaltze-erabakia, hostaren suebakia eta instantziaren aurreko hodeiko segurtasun-taldea. Hirurek bat etorri behar dute eta modu desberinetan huts egiten dute, horregatik goiko taulako sintoma nabigatzaileko errore-mezua baino erabilgarriagoa da.
Hostaren suebakia da lotura arrakastatsu baten ondoren jendeak ahazten duen geruza, LAN interfazean ataka baimentzen duen arauak ez baitu automatikoki baimenduko tunel interfazean. Interfazera mugatutako arauak diseinu zuzena dira eta aldi berean bulegotik funtzionatzen duen baina etxetik funtzionatzen ez duen zerbitzuaren ohiko arrazoia. Irakurri arauaren irismena, ez haren ataka-zenbakia.
Egoeran oinarritutako iragazketak alderantzizko kasua azaltzen du. Zure eramangarritik irteten den konexioak egoera sortzen du, eta haren erantzunak sarrerako araurik gabe onartzen dira. Lankidearen konexioa fluxu erabat berria da, atzean egoerarik gabea, beraz baimen esplizitua behar du. Asimetria hori da zure makina propioan funtzionatzen duen nabigatzaile-saio batek zerbitzua kanpotik irisgarria den ala ez ezer esaten ez duen arrazoi osoa.
Egiaztapen batek huts egiten duenean, aldatu diseinua, ez tunela
Baldintza lankide batek zure tokiko zerbitzua irekitzea bada, erantzun zintzoa normalean sarrerako sarbiderako eraikitako mekanismoa da. Alderantzizko SSH tunela txikiena da: zure makina kanpora konektatzen da lankideak jada irits dezakeen host batera, eta entzulea host horretan dago.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Erreleak GatewayPorts clientspecified behar du bere SSH zerbitzariaren konfigurazioan, bestela birbidalitako entzulea erreleko loopback-era lotzen da eta lankideak lehengo ukoa bera aurkitzen du. Arratsalde bat baino gehiago irauten duen edozertarako, karga-balantzatzailea edo ingress bat osasun-egiaztapenarekin eta argitaratutako izenerako ziurtagiriarekin tresna hobea da, eta gune arteko tunela bi azpisareen bideratzeekin da erantzun zuzena bi sarek benetan hitz egin behar dutenean.
Diseinu horietako bakoitzak esposizioa esplizitu bihurtzen du, eta hori da kontua. VPN batek paketeak mugitzen ditu jada baimenduta zenuen sareen artean; ez du zerbitzurik argitaratzen eta ez du eramangarria internetari begira dagoen host bihurtzen. Hiru geruzetatik zein aldatu erabakitzea da zeregina, eta tunela gutxitan da horietako bat.