Kial la adreso de via VPN-tunelo ne malfermas envenan pordon
Tunela adreso identigas vian klienton al samtavolanoj kiuj povas enkursigi al ĝi, kaj neniam kreas aŭskultanton. Kontrolu la ligon, la revenan vojon, poste la politikon.
Konektiĝu al la oficeja VPN, lanĉu malgrandan servon sur pordo 8443, sendu la tunelan adreson al kolego kaj observu la konekton malsukcesi dum la kliento daŭre raportas ke ĝi estas konektita. Nenio estas rompita en la tunelo: la adreso estis donita, la seanco estas aktiva, kaj la pakaĵoj kiuj portus la respondon simple neniam estas allasitaj. Faru la tri kontrolojn sube laŭ ordo kaj haltu ĉe la malsukcesa, ĉar ĉiu havas alian riparon kaj nur unu el ili temas pri la VPN.
Komencu per tio, kie la ingo estas efektive ligita
Antaŭ ol io ajn estas enkursigita, io devas aŭskulti sur adreso kiun la alvokanto povas atingi. Evoluigaj serviloj estas la kutima kulpulo, ĉar multaj el ili defaŭlte ligiĝas al loopback kaj akceptas nur konektojn kiuj originas sur la sama maŝino. Tunela adreso ne ŝanĝas tiun ligon, kaj la operaciumo rifuzos la konekton longe antaŭ ol la VPN iĝas implikita.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Legu la kolumnon de la loka adreso anstataŭ la staton. 127.0.0.1:8443 signifas nur loopback, kaj la ripare estas ligo al 0.0.0.0 aŭ al la tunela adreso mem. 0.0.0.0:8443 akceptas sur ĉiu interfaco, kio estas pli larĝa ol la plej multaj intencas kiam la maŝino ankaŭ havas publikan adreson; 10.64.7.15:8443 estas la mallarĝa versio kiu aŭskultas nur tie, kien la kolego povas atingi. Rimarku ankaŭ la procezan nomon en la sama eligo, ĉar restinta kazo el pli frua testo estas ofta kaŭzo ke la pordo aspektas malfermita kaj respondas per malĝusta enhavo.
Poste demandu ĉu io povas enkursigi al tiu adreso
Tunela adreso havas sencon nur por samtavolanoj agorditaj por sendi tiun prefikson en la tunelon. La maŝino de la kolego havas sian propran tabelon, kaj se ĝi ne havas vojon por la tunela subreto, la pakaĵo iras al la defaŭlta enirejo kaj mortas en loko kiu havas neniun ideon ke la adreso ekzistas. Tio estas enkursiga demando ĉe la flanko de la alvokanto, ne permeso ĉe via flanko.
| 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 |
La servilo inter la du klientoj same gravas. En la kutima dizajno de fora aliro ĉiu kliento malfermas eliran konekton al la enirejo, kaj la enirejo konservas staton por tiuj fluoj, do respondoj revenas per vojo kiun ĝi jam konas. Konekto de unu kliento al alia estas nova fluo kiun la enirejo devas akcepti kaj plusendi, kaj multaj deplojoj intence malŝaltas tion por teni klientojn izolitaj unu de la alia. Konsumantaj VPN-servoj kutime izolas defaŭlte; entreprenaj enirejoj foje permesas tion laŭ grupo.
Kontrolu la direkton antaŭ ol ŝanĝi ion ajn sur la gastiganto. Se la tunela adreso respondas de la enirejo mem sed ne de samtavolano, la diferenco estas la agordo kliento-al-kliento de la enirejo, kaj nenia redaktado de la loka fajromuro povas anstataŭigi ĝin.
Fine, trovu la politikon kiu permesas la fluon
Tri tavoloj de politiko staras inter enkursigita pakaĵo kaj servo kiu respondas: la plusenda decido de la VPN-servilo, la fajromuro de la gastiganto, kaj ajna nuba sekureca grupo antaŭ la kazo. Ĉiuj tri devas interkonsenti, kaj ili malsukcesas laŭ diversaj manieroj, tial la simptomo en la tabelo supre estas pli utila ol la erarmesaĝo en la retumilo.
La fajromuro de la gastiganto estas la tavolo kiun homoj forgesas post sukcesa ligo, ĉar regulo kiu permesas la pordon sur la LAN-interfaco ne aŭtomate permesas ĝin sur la tunela interfaco. Reguloj limigitaj al interfaco estas ĝusta dizajno kaj ankaŭ la kutima kaŭzo de servo kiu funkcias el la oficejo sed ne el hejmo. Legu la amplekson de la regulo, ne ĝian pordan numeron.
Statkonscia filtrado klarigas la inversan kazon. Elira konekto el via tekkomputilo kreas staton, kaj respondoj al ĝi estas allasitaj sen envena regulo. La konekto de la kolego estas tute nova fluo sen stato malantaŭ ĝi, do ĝi bezonas eksplicitan permeson. Tiu malsimetrio estas la tuta kaŭzo kial funkcianta retumila seanco sur via propra maŝino diras nenion pri tio ĉu la servo estas atingebla de ekstere.
Kiam unu kontrolo malsukcesas, ŝanĝu la dizajnon anstataŭ la tunelon
Se la postulo estas ke kolego malfermu vian lokan servon, la honesta respondo kutime estas mekanismo konstruita por envena aliro. Inversa SSH-tunelo estas la plej malgranda: via maŝino konektiĝas elire al gastiganto kiun la kolego jam povas atingi, kaj la aŭskultanto ekzistas sur tiu gastiganto.
ssh -N -R 8443:127.0.0.1:8443 [email protected]La relajso bezonas GatewayPorts clientspecified en sia SSH-servila agordo, alie la plusendita aŭskultanto ligiĝas al loopback sur la relajso kaj la kolego trafas la saman rifuzon kiel antaŭe. Por io ajn kio daŭras pli ol posttagmezo, ŝarĝbalancilo aŭ ingress kun sanokontrolo kaj atestilo por la publikigita nomo estas la pli bona ilo, kaj tunelo de ejo al ejo kun vojoj por ambaŭ subretoj estas la ĝusta respondo kiam du retoj vere devas paroli.
Ĉiu el tiuj dizajnoj igas la elmeton eksplicita, kaj tio estas la punkto. VPN movas pakaĵojn inter retoj kiujn vi jam rajtis uzi; ĝi ne publikigas servon kaj ne transformas tekkomputilon en gastiganton turnitan al la interreto. La tasko estas decidi kiun el la tri tavoloj ŝanĝi, kaj la tunelo malofte estas unu el ili.