Miks teie VPN-tunneli aadress ei ava sissetulevat porti
Tunneli aadress identifitseerib teie kliendi seadmetele, mis oskavad sinna marsruutida, ega loo kunagi kuulajat. Kontrollige sidumist, tagasiteed ja seejärel poliitikat.
Ühendage kontori VPN-iga, käivitage väike teenus pordil 8443, saatke tunneli aadress kolleegile ja jälgige, kuidas ühendus ebaõnnestub, samal ajal kui klient teatab endiselt, et on ühendatud. Tunnelis ei ole midagi katki: aadress anti välja, seanss on üleval ja paketid, mis vastuse kohale oleksid toonud, lihtsalt ei lasta kunagi läbi. Tehke kolm alltoodud kontrolli järjekorras ja peatuge sellel, mis ebaõnnestub, sest igal on erinev parandus ja ainult üks neist puudutab VPN-i.
Alustage sellest, kuhu socket tegelikult seotud on
Enne kui midagi marsruuditakse, peab miski kuulama aadressil, mille kutsuja jõuab. Arendusserverid on tavaline süüdlane, sest paljud neist seotakse vaikimisi loopbackiga ja need võtavad vastu ainult ühendusi, mis pärinevad samalt masinalt. Tunneli aadress ei muuda seda sidumist ja operatsioonisüsteem keeldub ühendusest ammu enne, kui VPN üldse mängu tuleb.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lugege pigem kohaliku aadressi veergu kui olekut. 127.0.0.1:8443 tähendab ainult loopbacki ja parandus on sidumine 0.0.0.0 või tunneli aadressi endaga. 0.0.0.0:8443 võtab vastu kõigil liidestel, mis on laiem, kui enamik kavatseb, kui masinal on ka avalik aadress; 10.64.7.15:8443 on kitsas versioon, mis kuulab ainult seal, kuhu kolleeg jõuab. Pange samas väljundis tähele ka protsessi nime, sest varasemast testist järele jäänud eksinud eksemplar on tavaline põhjus, miks port tundub avatud ja vastab vale sisuga.
Seejärel küsige, kas miski oskab sellele aadressile marsruutida
Tunneli aadressil on mõtet ainult nende seadmete jaoks, mis on seadistatud selle prefiksi tunnelisse saatma. Kolleegi masinal on oma tabel ja kui sellel pole tunneli alamvõrgu marsruuti, läheb pakett vaikimisi lüüsile ja sureb kohas, mis ei tea aadressi olemasolust midagi. See on marsruutimise küsimus kutsuja poolel, mitte luba teie poolel.
| 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 |
Server kahe kliendi vahel loeb sama palju. Tavalises kaugjuurdepääsu lahenduses avab iga klient väljuva ühenduse lüüsile ja lüüs hoiab nende voogude olekut, nii et vastused tulevad tagasi teed, mida ta juba teab. Ühendus ühest kliendist teise on uus voog, mille lüüs peab vastu võtma ja edasi saatma, ning paljud juurutused lülitavad selle meelega välja, et hoida kliente üksteisest isoleerituna. Tarbijate VPN-teenused isoleerivad tavaliselt vaikimisi; ettevõtte lüüsid lubavad seda mõnikord grupi kaupa.
Kontrollige suunda enne, kui muudate midagi hostis. Kui tunneli aadress vastab lüüsi enda poolt, aga mitte seadmelt, on erinevus lüüsi klient-kliendi seade, ja ükski kohaliku tulemüüri muudatus ei asenda seda.
Lõpuks leidke poliitika, mis voo lubab
Marsruuditud paketi ja vastava teenuse vahel on kolm poliitikakihti: VPN-serveri edastusotsus, hosti tulemüür ja mis tahes pilve turvagrupp eksemplari ees. Kõik kolm peavad nõustuma ja need ebaõnnestuvad erineval moel, seepärast on ülaltoodud tabeli sümptom kasulikum kui brauseri veateade.
Hosti tulemüür on kiht, mille inimesed pärast edukat sidumist unustavad, sest reegel, mis lubab porti LAN-liidesel, ei luba seda automaatselt tunneli liidesel. Liidesega piiratud reeglid on õige disain ja ka tavaline põhjus, miks teenus töötab kontorist, aga mitte kodust. Lugege reegli ulatust, mitte selle pordi numbrit.
Olekupõhine filtreerimine selgitab vastupidist juhtumit. Väljuv ühendus teie sülearvutist loob oleku ja vastused sellele lastakse läbi ilma sissetuleva reeglita. Kolleegi ühendus on täiesti uus voog, mille taga olekut pole, seega vajab see selget luba. See asümmeetria on kogu põhjus, miks töötav brauseriseanss teie enda masinas ei ütle midagi selle kohta, kas teenus on väljast kättesaadav.
Kui üks kontroll ebaõnnestub, muutke disaini, mitte tunnelit
Kui nõue on, et kolleeg avaks teie kohaliku teenuse, on aus vastus tavaliselt sissetuleva juurdepääsu jaoks ehitatud mehhanism. Pööratud SSH-tunnel on väikseim: teie masin ühendub väljapoole hostiga, kuhu kolleeg juba jõuab, ja kuulaja asub sellel hostil.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relee vajab oma SSH-serveri konfiguratsioonis GatewayPorts clientspecified, muidu seotakse edastatud kuulaja releel loopbackiga ja kolleeg kohtab sama keeldumist kui varem. Kõige jaoks, mis kestab kauem kui üks pärastlõuna, on parem tööriist koormusjaotur või ingress koos tervisekontrolli ja avaldatud nime sertifikaadiga, ning saidi ja saidi vaheline tunnel mõlema alamvõrgu marsruutidega on õige vastus, kui kaks võrku peavad tõesti rääkima.
Iga selline disain muudab kokkupuute selgesõnaliseks ja see ongi mõte. VPN liigutab pakette võrkude vahel, mille kasutamiseks olite juba volitatud; see ei avalda teenust ega muuda sülearvutit internetti vaatavaks hostiks. Ülesanne on otsustada, millist kolmest kihist muuta, ja tunnel on neist harva üks.