Bakit hindi nagbubukas ng papasok na port ang address ng iyong VPN tunnel
Kinikilala ng address ng tunnel ang iyong kliyente sa mga peer na makakapag-route patungo rito, at hindi kailanman gumagawa ng tagapakinig. Suriin ang pagkakabit, ang rutang pabalik, at pagkatapos ang patakaran.
Kumonekta sa VPN ng opisina, magsimula ng maliit na serbisyo sa port 8443, ipadala ang address ng tunnel sa isang kasamahan, at panoorin ang koneksyon na mabigo habang ang kliyente ay nag-uulat pa ring konektado. Walang sira sa tunnel: naibigay ang address, aktibo ang sesyon, at ang mga packet na magdadala sana ng sagot ay hindi kailanman pinapasok. Gawin ang tatlong pagsusuri sa ibaba nang sunud-sunod at huminto sa nabibigo, dahil bawat isa ay may ibang pagwawasto at isa lamang sa kanila ang tungkol sa VPN.
Magsimula sa kung saan talaga nakakabit ang socket
Bago mag-route ng anuman, may dapat makinig sa isang address na maaabot ng tumatawag. Ang mga development server ang karaniwang salarin, dahil marami sa kanila ay kumakabit sa loopback bilang default at tumatanggap lamang ng mga koneksyong nagmumula sa parehong makina. Hindi binabago ng address ng tunnel ang pagkakabit na iyon, at tatanggihan ng operating system ang koneksyon bago pa man masangkot ang VPN.
ss -ltnp | grep 8443
netstat -ano | findstr 8443
Basahin ang hanay ng lokal na address, hindi ang estado. Ang 127.0.0.1:8443 ay loopback lamang, at ang pagwawasto ay pagkakabit sa 0.0.0.0 o sa mismong address ng tunnel. Ang 0.0.0.0:8443 ay tumatanggap sa lahat ng interface, na mas malawak kaysa sa karaniwang nilalayon ng mga tao kapag may pampublikong address din ang makina; ang 10.64.7.15:8443 ay ang makitid na bersyon na nakikinig lamang kung saan maaabot ito ng kasamahan. Pansinin din ang pangalan ng proseso sa parehong output, dahil ang naiwang instance mula sa naunang pagsubok ay karaniwang dahilan kung bakit mukhang bukas ang port at sumasagot nang maling nilalaman.
Pagkatapos itanong kung may makakapag-route patungo sa address na iyon
May kahulugan lamang ang address ng tunnel para sa mga peer na naka-configure na ipadala ang prefix na iyon sa loob ng tunnel. May sariling talahanayan ang makina ng kasamahan, at kung walang ruta patungo sa subnet ng tunnel, pupunta ang packet sa default gateway at mamamatay sa lugar na walang ideya na umiiral ang address. Tanong ito ng pag-route sa panig ng tumatawag, hindi pahintulot sa panig mo.
| 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 |
Ang server sa pagitan ng dalawang kliyente ay kasinghalaga rin. Sa karaniwang disenyo ng malayong pag-access, bawat kliyente ay nagbubukas ng palabas na koneksyon sa gateway at inaasikaso ng gateway ang estado ng mga flow na iyon, kaya bumabalik ang mga sagot sa landas na alam na nito. Ang koneksyon mula sa isang kliyente patungo sa isa pa ay bagong flow na dapat tanggapin at ipasa ng gateway, at sinasadya ng maraming deployment na patayin iyon upang manatiling hiwalay ang mga kliyente sa isa't isa. Karaniwang naghihiwalay ang mga consumer VPN service bilang default; pinapayagan ito ng mga corporate gateway kung minsan ayon sa grupo.
Suriin ang direksyon bago magbago ng anuman sa host. Kung sumasagot ang address ng tunnel mula sa gateway mismo ngunit hindi mula sa isang peer, ang pagkakaiba ay ang setting ng kliyente-sa-kliyente ng gateway, at walang pag-edit ng lokal na firewall ang makapapalit doon.
Sa huli, hanapin ang patakarang nagpapahintulot sa daloy
Tatlong suson ng patakaran ang nasa pagitan ng naka-route na packet at ng serbisyong sumasagot: ang desisyon ng pagpapasa ng VPN server, ang firewall ng host, at anumang cloud security group sa harap ng instance. Kailangang magkasundo ang tatlo, at nabibigo sila sa iba't ibang paraan, kaya mas kapaki-pakinabang ang sintomas sa talahanayan sa itaas kaysa sa mensahe ng error sa browser.
Ang firewall ng host ang suson na nakakalimutan ng mga tao pagkatapos ng matagumpay na pagkakabit, dahil ang patakarang nagpapahintulot sa port sa interface ng LAN ay hindi awtomatikong nagpapahintulot nito sa interface ng tunnel. Ang mga patakarang limitado sa interface ay tamang disenyo at karaniwang dahilan din ng serbisyong gumagana mula sa opisina at hindi mula sa bahay. Basahin ang saklaw ng patakaran, hindi ang numero ng port.
Ipinapaliwanag ng stateful filtering ang kabaligtarang kaso. Ang palabas na koneksyon mula sa iyong laptop ay lumilikha ng estado, at ang mga sagot dito ay pinapasok nang walang papasok na patakaran. Ang koneksyon ng kasamahan ay ganap na bagong daloy na walang estado sa likod nito, kaya kailangan nito ng malinaw na pahintulot. Ang asimetriyang iyon ang buong dahilan kung bakit ang gumaganang sesyon ng browser sa sarili mong makina ay walang sinasabi tungkol sa kung maaabot ang serbisyo mula sa labas.
Kapag nabigo ang isang pagsusuri, baguhin ang disenyo at hindi ang tunnel
Kung ang pangangailangan ay buksan ng kasamahan ang iyong lokal na serbisyo, ang tapat na sagot ay karaniwang mekanismong ginawa para sa papasok na pag-access. Ang baliktad na SSH tunnel ang pinakamaliit: lumalabas na kumokonekta ang iyong makina sa host na maaabot na ng kasamahan, at ang tagapakinig ay nasa host na iyon.
ssh -N -R 8443:127.0.0.1:8443 [email protected]
Kailangan ng relay ang GatewayPorts clientspecified sa configuration ng SSH server nito, kung hindi ay kumakabit ang ipinasang tagapakinig sa loopback sa relay at nararanasan ng kasamahan ang parehong pagtanggi tulad ng dati. Para sa anumang tatagal nang higit sa isang hapon, ang load balancer o ingress na may health check at certificate para sa nailathalang pangalan ang mas mabuting kasangkapan, at ang site-to-site na tunnel na may ruta para sa dalawang subnet ang tamang sagot kapag talagang kailangang mag-usap ang dalawang network.
Ginagawang malinaw ng bawat isa sa mga disenyong iyon ang pagkalantad, at iyon ang punto. Inililipat ng VPN ang mga packet sa pagitan ng mga network na awtorisado ka nang gamitin; hindi ito naglalathala ng serbisyo at hindi ginagawang host na nakaharap sa internet ang isang laptop. Ang gawain ay magpasya kung alin sa tatlong suson ang babaguhin, at bihirang isa sa kanila ang tunnel.