Kodėl jūsų VPN tunelio adresas neatveria įeinančio prievado
Tunelio adresas identifikuoja jūsų klientą tiems partneriams, kurie gali į jį maršrutizuoti, ir niekada nesukuria klausytojo. Patikrinkite susiejimą, grįžimo maršrutą, tada politiką.
Prisijunkite prie biuro VPN, paleiskite nedidelę paslaugą 8443 prievade, nusiųskite tunelio adresą kolegai ir stebėkite, kaip ryšys nepavyksta, nors klientas vis dar praneša esąs prisijungęs. Tunelyje niekas nesugedę: adresas buvo išduotas, sesija aktyvi, o paketai, kurie perneštų atsakymą, tiesiog niekada nepraleidžiami. Atlikite tris patikras žemiau iš eilės ir sustokite ties ta, kuri nepavyksta, nes kiekviena turi skirtingą pataisą ir tik viena jų susijusi su VPN.
Pradėkite nuo to, kur lizdas iš tikrųjų susietas
Prieš ką nors maršrutizuojant, kažkas turi klausytis adresu, kurį pasieks skambinantysis. Kūrimo serveriai yra įprasti kaltininkai, nes daugelis jų pagal nutylėjimą susiejami su loopback ir priima tik ryšius, kylančius iš tos pačios mašinos. Tunelio adresas šio susiejimo nekeičia, o operacinė sistema atmes ryšį gerokai anksčiau, nei VPN apskritai bus įtrauktas.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Skaitykite vietinio adreso stulpelį, o ne būseną. 127.0.0.1:8443 reiškia tik loopback, o pataisa – susiejimas su 0.0.0.0 arba pačiu tunelio adresu. 0.0.0.0:8443 priima visuose sąsajose, o tai platesnė apimtis, nei dauguma numato, kai mašina turi ir viešą adresą; 10.64.7.15:8443 – siaura versija, kuri klausosi tik ten, kur kolega gali pasiekti. Atkreipkite dėmesį ir į proceso pavadinimą toje pačioje išvestyje, nes pasilikusi ankstesnio testo egzemplioriaus kopija yra dažna priežastis, kodėl prievadas atrodo atidarytas ir atsako netinkamu turiniu.
Tada paklauskite, ar kas nors gali maršrutizuoti į tą adresą
Tunelio adresas turi prasmę tik tiems partneriams, kurie sukonfigūruoti siųsti tą priešdėlį į tunelį. Kolegos mašina turi savo lentelę, ir jei neturi maršruto į tunelio potinklį, paketas eina į numatytąją šliuzą ir žūva vietoje, kuri net neįsivaizduoja, kad adresas egzistuoja. Tai maršrutizavimo klausimas skambinančiojo pusėje, o ne leidimas jūsų pusėje.
| 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 |
Serveris tarp dviejų klientų yra ne mažiau svarbus. Įprastoje nuotolinės prieigos schemoje kiekvienas klientas atidaro išeinantį ryšį į šliuzą, o šliuzas saugo tų srautų būseną, todėl atsakymai grįžta keliu, kurį jis jau žino. Ryšys iš vieno kliento į kitą yra naujas srautas, kurį šliuzas turi priimti ir persiųsti, ir daug diegimų tai sąmoningai išjungia, kad klientai liktų izoliuoti vienas nuo kito. Vartotojų VPN paslaugos paprastai izoliuoja pagal nutylėjimą; įmonių šliuzai kartais tai leidžia pagal grupes.
Patikrinkite kryptį prieš ką nors keisdami pagrindinėje mašinoje. Jei tunelio adresas atsako iš paties šliuzo, bet ne iš partnerio, skirtumas yra šliuzo nuostata klientas-klientui, ir joks vietinės užkardos redagavimas to nepakeis.
Galiausiai raskite politiką, kuri leidžia srautą
Trys politikos sluoksniai yra tarp maršrutizuoto paketo ir atsakančios paslaugos: VPN serverio persiuntimo sprendimas, pagrindinės mašinos užkarda ir bet kokia debesijos saugumo grupė prieš egzempliorių. Visi trys turi sutarti, ir jie nepavyksta skirtingais būdais, todėl simptomas aukščiau esančioje lentelėje yra naudingesnis už klaidos pranešimą naršyklėje.
Pagrindinės mašinos užkarda yra sluoksnis, kurį žmonės pamiršta po sėkmingo susiejimo, nes taisyklė, leidžianti prievadą LAN sąsajoje, automatiškai neleidžia jo tunelio sąsajoje. Sąsaja apribotos taisyklės yra teisingas dizainas ir kartu įprasta priežastis paslaugos, kuri veikia iš biuro, bet ne iš namų. Skaitykite taisyklės apimtį, o ne jos prievado numerį.
Būsenos sekimas paaiškina priešingą atvejį. Išeinantis ryšys iš jūsų nešiojamojo kompiuterio sukuria būseną, ir atsakymai į jį praleidžiami be įeinančios taisyklės. Kolegos ryšys yra visiškai naujas srautas be būsenos už jo, todėl jam reikia aiškaus leidimo. Ši asimetrija yra visa priežastis, kodėl veikianti naršyklės sesija jūsų pačių mašinoje nieko nesako apie tai, ar paslauga pasiekiama iš išorės.
Kai viena patikra nepavyksta, keiskite dizainą, o ne tunelį
Jei reikalavimas yra, kad kolega atidarytų jūsų vietinę paslaugą, sąžiningas atsakymas paprastai yra mechanizmas, sukurtas įeinančiai prieigai. Atvirkštinis SSH tunelis yra mažiausias: jūsų mašina išeidama jungiasi prie pagrindinės mašinos, kurią kolega jau gali pasiekti, ir klausytojas egzistuoja toje mašinoje.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relė savo SSH serverio konfigūracijoje turi turėti GatewayPorts clientspecified, kitaip persiųstas klausytojas prisiriša prie loopback relėje ir kolega susiduria su tuo pačiu atmetimu kaip anksčiau. Viskam, kas trunka ilgiau nei popietę, apkrovos balansuotojas arba ingress su sveikatos patikra ir sertifikatu paskelbtam vardui yra geresnis įrankis, o tunelis tarp vietovių su maršrutais abiem potinkliams yra teisingas atsakymas, kai du tinklai tikrai turi kalbėtis.
Kiekvienas iš šių dizainų padaro poveikį aiškų, ir tai yra esmė. VPN perkelia paketus tarp tinklų, kuriuos naudoti jau buvote įgaliotas; jis neskelbia paslaugos ir nepaverčia nešiojamojo kompiuterio į internetą atgręžta mašina. Užduotis yra nuspręsti, kurį iš trijų sluoksnių keisti, ir tunelis retai būna vienas iš jų.