Zakaj naslov vašega tunela VPN ne odpre vhodnih vrat
Naslov tunela identificira vašega odjemalca partnerjem, ki lahko usmerjajo do njega, in nikoli ne ustvari poslušalca. Preverite vezavo, povratno pot in nato politiko.
Povežite se z VPN pisarne, zaženite majhno storitev na vratih 8443, pošljite naslov tunela sodelavcu in opazujte, kako povezava ne uspe, medtem ko odjemalec še vedno poroča, da je povezan. V tunelu ni nič pokvarjeno: naslov je bil dodeljen, seja je aktivna, paketi, ki bi nosili odgovor, pa preprosto nikoli niso spuščeni. Izvedite tri spodnje preveritve po vrsti in ustavite se pri tisti, ki ne uspe, ker ima vsaka drugačno popravilo in le ena od njih se nanaša na VPN.
Začnite s tem, kam je vtičnica v resnici vezana
Preden se karkoli usmeri, mora nekaj poslušati na naslovu, ki ga klicatelj lahko doseže. Razvojni strežniki so običajni krivec, ker se mnogi privzeto vežejo na loopback in sprejemajo samo povezave z istega stroja. Naslov tunela te vezave ne spremeni, operacijski sistem pa bo povezavo zavrnil veliko prej, preden bo VPN sploh vpleten.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Berite stolpec lokalnega naslova, ne stanja. 127.0.0.1:8443 pomeni samo loopback, popravilo pa je vezava na 0.0.0.0 ali na sam naslov tunela. 0.0.0.0:8443 sprejema na vseh vmesnikih, kar je širše, kot večina namerava, ko ima stroj tudi javni naslov; 10.64.7.15:8443 je ozka različica, ki posluša le tam, kamor lahko pride sodelavec. Bodite pozorni tudi na ime procesa v istem izhodu, ker je zalutala instanca iz prejšnjega testa pogost razlog, da so vrata videti odprta in odgovarjajo z napačno vsebino.
Nato vprašajte, ali lahko karkoli usmerja do tega naslova
Naslov tunela ima smisel samo za partnerje, ki so nastavljeni tako, da to predpono pošiljajo v tunel. Sodelavčev stroj ima svojo tabelo in brez poti do podomrežja tunela paket odide na privzeti prehod in umre na mestu, ki ne ve, da naslov obstaja. To je vprašanje usmerjanja na strani klicatelja, ne dovoljenje na vaši strani.
| 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 |
Strežnik med obema odjemalcema šteje prav toliko. V običajni zasnovi oddaljenega dostopa vsak odjemalec odpre odhodno povezavo do prehoda, prehod pa hrani stanje teh tokov, zato se odgovori vračajo po poti, ki jo že pozna. Povezava od enega odjemalca do drugega je nov tok, ki ga mora prehod sprejeti in posredovati, in številne namestitve to namerno izklopijo, da ohranijo odjemalce ločene med seboj. Potrošniške storitve VPN običajno privzeto ločujejo; poslovni prehodi to včasih dovolijo po skupinah.
Preverite smer, preden karkoli spremenite na gostitelju. Če naslov tunela odgovarja s prehoda samega, ne pa s partnerja, je razlika v nastavitvi odjemalec-odjemalec na prehodu, in nobeno urejanje lokalnega požarnega zidu je ne more nadomestiti.
Nazadnje poiščite politiko, ki tok dovoljuje
Med usmerjenim paketom in storitvijo, ki odgovarja, so tri plasti politike: odločitev strežnika VPN o posredovanju, požarni zid gostitelja in morebitna oblačna varnostna skupina pred instanco. Vse tri se morajo ujemati in ne uspevajo na različne načine, zato je simptom v zgornji tabeli uporabnejši od sporočila o napaki v brskalniku.
Požarni zid gostitelja je plast, ki jo ljudje po uspešni vezavi pozabijo, ker pravilo, ki dovoli vrata na vmesniku LAN, tega ne dovoli samodejno na vmesniku tunela. Pravila, omejena na vmesnik, so pravilna zasnova in hkrati pogost vzrok storitve, ki deluje iz pisarne in ne od doma. Berite obseg pravila, ne številke vrat.
Filtriranje s stanjem pojasni nasprotni primer. Odhodna povezava z vašega prenosnika ustvari stanje in odgovori nanjo so spuščeni brez vhodnega pravila. Sodelavčeva povezava je povsem nov tok brez stanja za seboj, zato potrebuje izrecno dovoljenje. Ta asimetrija je ves razlog, da delujoča seja brskalnika na vašem lastnem stroju ne pove ničesar o tem, ali je storitev dosegljiva od zunaj.
Ko ena preveritev ne uspe, spremenite zasnovo, ne tunela
Če je zahteva, da sodelavec odpre vašo lokalno storitev, je pošten odgovor običajno mehanizem, zgrajen za vhodni dostop. Obrnjen tunel SSH je najmanjši: vaš stroj se odhodno poveže z gostiteljem, ki ga sodelavec že doseže, in poslušalec obstaja na tem gostitelju.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Posredovalnik potrebuje GatewayPorts clientspecified v konfiguraciji strežnika SSH, sicer se posredovani poslušalec veže na loopback na posredovalniku in sodelavec naleti na enako zavrnitev kot prej. Za vse, kar traja dlje kot popoldne, je boljše orodje uravnavalnik obremenitve ali ingress s preverjanjem stanja in potrdilom za objavljeno ime, tunel med lokacijama s potmi za obe podomrežji pa je pravi odgovor, ko morata dve omrežji res govoriti.
Vsaka od teh zasnov naredi izpostavljenost izrecno, in to je poanta. VPN premika pakete med omrežji, za katera ste že bili pooblaščeni; ne objavi storitve in ne spremeni prenosnika v gostitelja, obrnjenega v internet. Naloga je odločiti, katero od treh plasti spremeniti, in tunel je redko ena od njih.