Wêrom't it adres fan jo VPN-tunnel gjin yngeande poarte iepenet
In tunneladres identifisearret jo klant foar peers dy't dernei route kinne, en makket nea in harker. Kontrolearje de binding, de weromrûte en dan it belied.
Ferbynje jo mei de VPN fan it kantoar, start in lytse tsjinst op poarte 8443, stjoer it tunneladres nei in kollega en sjoch hoe't de ferbining mislearret wylst de klant noch altyd meldt dat er ferbûn is. Der is neat stikken yn 'e tunnel: it adres is útjûn, de sesje is aktyf en de pakketten dy't it antwurd drage soenen wurde gewoan nea tastien. Doch de trije kontrôles hjirûnder yn folchoarder en stop by dejinge dy't mislearret, want elk hat in oare oplossing en mar ien fan har giet oer de VPN.
Begjin by wêr't de socket eins oan bûn is
Foar't eat route wurdt, moat eat harkje op in adres dat de oanropper berikke kin. Untjouwingsservers binne de gewoane skuldige, want in protte fan har binne standert oan loopback bûn en akseptearje allinnich ferbiningen dy't fan deselde masine komme. In tunneladres feroaret dy binding net, en it bestjoeringssysteem sil de ferbining wegerje lang foar't de VPN der by belutsen is.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lês de kolom fan it lokale adres ynstee fan de tastân. 127.0.0.1:8443 betsjut allinnich loopback, en de oplossing is in binding op 0.0.0.0 of op it tunneladres sels. 0.0.0.0:8443 akseptearret op alle ynterfaces, wat breder is as de measte minsken bedoele as de masine ek in iepenbier adres hat; 10.64.7.15:8443 is de smelle ferzje dy't allinnich harket wêr't de kollega komme kin. Tink ek om de namme fan it proses yn deselde útfier, want in fertoarne eksimplaar fan in eardere test is in gewoane oarsaak dat de poarte iepen liket en mei ferkearde ynhâld antwurdet.
Freegje dan oft eat nei dat adres route kin
In tunneladres hat allinnich betsjutting foar peers dy't konfigurearre binne om dat foarheaksel de tunnel yn te stjoeren. De masine fan de kollega hat syn eigen tabel, en as der gjin rûte nei it tunnelsubnet is, giet it pakket nei de standertgateway en stjert it op in plak dat gjin idee hat dat it adres bestiet. Dat is in routingfraach oan 'e kant fan de oanropper, gjin tastimming oan jo kant.
| 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 |
De server tusken de twa klanten telt likefolle. Yn it gewoane ûntwerp foar tagong op ôfstân iepenet elke klant in útgeande ferbining nei de gateway en de gateway hâldt de tastân fan dy streams by, sadat antwurden weromkomme oer in paad dat er al ken. In ferbining fan de iene klant nei de oare is in nije stream dy't de gateway akseptearje en trochstjoere moat, en in protte ymplemintaasjes skeakelje dat bewust út om klanten fan elkoar isolearre te hâlden. Konsuminte-VPN-tsjinsten isolearje meastentiids standert; bedriuwsgateways tastean it soms per groep.
Kontrolearje de rjochting foar't jo eat op 'e host feroarje. As it tunneladres antwurdet fan 'e gateway sels mar net fan in peer, is de ynstelling fan 'e gateway foar klant-nei-klant it ferskil, en gjin inkelde bewurking fan 'e lokale firewall kin dat ferfange.
Fyn úteinlik it belied dat de stream tastiet
Trije beliedslagen steane tusken in routearre pakket en in tsjinst dy't antwurdet: it trochstjoerbeslút fan de VPN-server, de firewall fan 'e host en elke cloudfeilichheidsgroep foar de eksimplaar. Alle trije moatte it iens wêze en se mislearje op ferskate manieren, dêrom is it symptoom yn 'e tabel hjirboppe nuttiger as it flaterberjocht yn 'e browser.
De firewall fan 'e host is de laach dy't minsken ferjitte nei in suksesfolle binding, want in regel dy't de poarte op 'e LAN-ynterface tastiet, tastiet him net automatysk op 'e tunnel-ynterface. Regels beheind ta in ynterface binne korrekt ûntwerp en ek de gewoane oarsaak fan in tsjinst dy't fan it kantoar ôf wurket en net fan hûs ôf. Lês de omfang fan 'e regel, net it poartenûmer.
Tastânfiltraasje ferklearret it omkearde gefal. In útgeande ferbining fan jo laptop makket tastân, en antwurden dêrop wurde tastien sûnder yngeande regel. De ferbining fan 'e kollega is in gloednije stream sûnder tastân der efter, dus hy hat in eksplisite tastimming nedich. Dy asymmetry is de hiele reden dat in wurkjende browsersesje op jo eigen masine neat seit oer oft de tsjinst fan bûten berikber is.
As ien kontrôle mislearret, feroarje it ûntwerp ynstee fan 'e tunnel
As de eask is dat in kollega jo lokale tsjinst iepenet, is it earlike antwurd meastentiids in meganisme boud foar yngeande tagong. In omkearde SSH-tunnel is de lytste: jo masine ferbynt útgeand nei in host dêr't de kollega al komme kin, en de harker bestiet op dy host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]It relais hat GatewayPorts clientspecified nedich yn 'e konfiguraasje fan syn SSH-server, oars bûn de trochstjoerde harker him op it relais oan loopback en kriget de kollega deselde wegering as earder. Foar alles wat langer duorret as in middei is in loadbalancer of ingress mei in sûnenscheck en in sertifikaat foar de publisearre namme it bettere ynstrumint, en in tunnel fan side nei side mei rûtes foar beide subnetten is it juste antwurd as twa netwurken wier mei elkoar prate moatte.
Elk fan dy ûntwerpen makket de bleatstelling eksplisyt, en dat is it punt. In VPN ferpleatst pakketten tusken netwurken dêr't jo al foar autorisearre wiene; hy publisearret gjin tsjinst en makket fan in laptop gjin host dy't nei it ynternet rjochte is. Beslute hokker fan 'e trije lagen te feroarjen is de taak, en de tunnel is dêr selden ien fan.