Waarom jou VPN-tonneladres nie 'n inkomende poort oopmaak nie
'n Tonneladres identifiseer jou kliënt vir eweknieë wat daarheen kan roeteer, en skep nooit 'n luisteraar nie. Kontroleer die binding, die terugroete, dan die beleid.
Koppel aan die kantoor se VPN, begin 'n klein diens op poort 8443, stuur die tonneladres vir 'n kollega, en kyk hoe die verbinding misluk terwyl die kliënt steeds rapporteer dat dit gekoppel is. Niks is in die tonnel fout nie: die adres is uitgegee, die sessie is op, en die pakkies wat die antwoord sou dra, word eenvoudig nooit toegelaat nie. Werk die drie kontroles hieronder in volgorde deur en stop by die een wat misluk, want elkeen het 'n ander regstelling en net een daarvan gaan oor die VPN.
Begin by waar die sokkie werklik gebind is
Voordat enigiets roeteer, moet iets luister op 'n adres wat die oproeper kan bereik. Ontwikkelingsbedieners is die gewone oortreder, want baie van hulle bind by verstek aan loopback en aanvaar net verbindings wat op dieselfde masjien ontstaan. 'n Tonneladres verander nie daardie binding nie, en die bedryfstelsel sal die verbinding weier lank voordat die VPN betrokke raak.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lees die plaaslike adreskolom eerder as die toestand. 127.0.0.1:8443 beteken net loopback, en die regstelling is 'n binding op 0.0.0.0 of op die tonneladres self. 0.0.0.0:8443 aanvaar op elke koppelvlak, wat wyer is as wat die meeste mense bedoel wanneer die masjien ook 'n openbare adres het; 10.64.7.15:8443 is die smal weergawe wat net luister waar die kollega dit kan bereik. Let op die prosesnaam in dieselfde uitset, want 'n verdwaalde instansie van 'n vroeëre toets is 'n algemene rede waarom die poort oop lyk en met die verkeerde inhoud antwoord.
Vra dan of enigiets na daardie adres kan roeteer
'n Tonneladres het net betekenis vir eweknieë wat ingestel is om daardie voorvoegsel in die tonnel te stuur. Die kollega se masjien het sy eie tabel, en tensy dit 'n roete vir die tonnelsubnet het, gaan die pakkie na die verstekgateway en sterf op 'n plek wat geen idee het die adres bestaan nie. Dit is 'n roetevraag aan die oproeper se kant, nie 'n toestemming aan jou kant nie.
| 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 |
Die bediener tussen die twee kliënte maak net so veel saak. In die algemene ontwerp vir afstandtoegang maak elke kliënt 'n uitwaartse verbinding na die gateway oop, en die gateway hou toestand vir daardie vloei, sodat antwoorde terugkom op 'n pad wat hy reeds ken. 'n Verbinding van een kliënt na 'n ander is 'n nuwe vloei wat die gateway moet aanvaar en deurstuur, en baie ontplooiings skakel dit doelbewus af om kliënte van mekaar geïsoleer te hou. Verbruiker-VPN-dienste isoleer gewoonlik by verstek; korporatiewe gateways laat dit soms per groep toe.
Kontroleer die rigting voordat jy enigiets op die gasheer verander. As die tonneladres vanaf die gateway self antwoord maar nie vanaf 'n eweknie nie, is die gateway se kliënt-tot-kliënt-instelling die verskil, en geen hoeveelheid plaaslike firewallwysiging sal daarvoor kan instaan nie.
Vind uiteindelik die beleid wat die vloei toelaat
Drie beleidslae sit tussen 'n geroteerde pakkie en 'n diens wat antwoord: die VPN-bediener se deurstuurbesluit, die gasheerfirewall, en enige wolk-sekuriteitsgroep voor die instansie. Al drie moet saamstem, en hulle misluk op verskillende maniere, daarom is die simptoom in die tabel hierbo nuttiger as die foutboodskap in die blaaier.
Die gasheerfirewall is die laag wat mense ná 'n suksesvolle binding vergeet, want 'n reël wat die poort op die LAN-koppelvlak toelaat, laat dit nie outomaties op die tonnelkoppelvlak toe nie. Reëls wat op 'n koppelvlak gemik is, is korrekte ontwerp en is ook die gewone oorsaak van 'n diens wat van die kantoor af werk en nie van die huis af nie. Lees die reël se omvang eerder as sy poortnommer.
Toestandgebaseerde filtering verduidelik die omgekeerde geval. 'n Uitwaartse verbinding van jou skootrekenaar skep toestand, en antwoorde daarop word toegelaat sonder 'n inkomende reël. 'n Kollega se verbinding is 'n splinternuwe vloei met geen toestand agter hom nie, so dit het 'n eksplisiete toelating nodig. Daardie asimmetrie is die hele rede waarom 'n werkende blaaiersessie op jou eie masjien niks sê oor of die diens van buite bereikbaar is nie.
Wanneer een kontrole misluk, verander die ontwerp eerder as die tonnel
As die vereiste is dat 'n kollega jou plaaslike diens oopmaak, is die eerlike antwoord gewoonlik 'n meganisme wat vir inkomende toegang gebou is. 'n Omgekeerde SSH-tonnel is die kleinste een: jou masjien verbind uitwaarts na 'n gasheer wat die kollega reeds kan bereik, en die luisteraar bestaan op daardie gasheer.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Die aflos het GatewayPorts clientspecified in sy SSH-bedienerkonfigurasie nodig, anders bind die deurgestuurde luisteraar aan loopback op die aflos en kry die kollega dieselfde weiering as vantevore. Vir enigiets wat langer as 'n middag hou, is 'n lasbalanseerder of ingress met 'n gesondheidskontrole en 'n sertifikaat vir die gepubliseerde naam die beter instrument, en 'n werf-tot-werf-tonnel met roetes vir beide subnette is die regte antwoord wanneer twee netwerke werklik moet praat.
Elkeen van daardie ontwerpe maak die blootstelling eksplisiet, en dit is die punt. 'n VPN skuif pakkies tussen netwerke waarvoor jy reeds gemagtig was; dit publiseer nie 'n diens nie en verander nie 'n skootrekenaar in 'n gasheer wat aan die internet blootgestel is nie. Om te besluit watter van die drie lae om te verander, is die taak, en die tonnel is selde een van hulle.