Pse adresa e tunelit VPN nuk hap një port hyrës
Një adresë tuneli identifikon klientin tuaj ndaj palëve që mund të drejtojnë trafik drejt saj dhe nuk krijon kurrë një dëgjues. Kontrollo lidhjen, rrugën e kthimit, pastaj politikën.
Lidhu me VPN-në e zyrës, nis një shërbim të vogël në portën 8443, dërgo adresën e tunelit një kolegu dhe shiko lidhjen duke dështuar ndërsa klienti vazhdon të raportojë se është i lidhur. Asgjë nuk është prishur në tunel: adresa u nda, sesioni është aktiv dhe paketat që do të mbanin përgjigjen thjesht nuk pranohen kurrë. Kryej tre kontrollet më poshtë me radhë dhe ndalo tek ai që dështon, sepse secili ka një rregullim tjetër dhe vetëm një prej tyre ka të bëjë me VPN-në.
Fillo nga vendi ku socket-i është vërtet i lidhur
Përpara se diçka të drejtohet, diçka duhet të dëgjojë në një adresë që thirrësi mund ta arrijë. Serverat e zhvillimit janë fajtori i zakonshëm, sepse shumë prej tyre lidhen si parazgjedhje me loopback dhe pranojnë vetëm lidhje që vijnë nga e njëjta makinë. Adresa e tunelit nuk e ndryshon këtë lidhje dhe sistemi operativ do ta refuzojë lidhjen shumë përpara se VPN-ja të përfshihet.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lexo kolonën e adresës lokale, jo statusin. 127.0.0.1:8443 do të thotë vetëm loopback, dhe rregullimi është një lidhje në 0.0.0.0 ose në vetë adresën e tunelit. 0.0.0.0:8443 pranon në të gjitha ndërfaqet, çka është më e gjerë se sa synon shumica kur makina ka edhe një adresë publike; 10.64.7.15:8443 është versioni i ngushtë që dëgjon vetëm aty ku kolegu mund të arrijë. Vër re edhe emrin e procesit në të njëjtin dalje, sepse një instancë e mbetur nga një test i mëparshëm është një shkak i zakonshëm që porta të duket e hapur dhe të përgjigjet me përmbajtje të gabuar.
Pastaj pyet nëse diçka mund të drejtojë drejt asaj adrese
Një adresë tuneli ka kuptim vetëm për palët e konfiguruara për ta dërguar atë prefiks brenda tunelit. Makina e kolegut ka tabelën e vet dhe, nëse nuk ka rrugë për nënrrjetin e tunelit, paketa shkon te porta e parazgjedhur dhe vdes në një vend që nuk e di se adresa ekziston. Kjo është çështje drejtimi në anën e thirrësit, jo leje në anën tuaj.
| 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 |
Serveri mes dy klientëve ka po aq rëndësi. Në ndërtimin e zakonshëm të aksesit në distancë, secili klient hap një lidhje dalëse drejt portës dhe porta mban gjendjen e atyre rrjedhave, kështu që përgjigjet kthehen në një rrugë që ai e njeh tashmë. Një lidhje nga një klient në tjetrin është një rrjedhë e re që porta duhet ta pranojë dhe ta përcjellë, dhe shumë instalime e çaktivizojnë këtë me qëllim për t'i mbajtur klientët të izoluar nga njëri-tjetri. Shërbimet VPN për konsumatorë zakonisht izolojnë si parazgjedhje; portat korporative ndonjëherë e lejojnë atë sipas grupit.
Kontrollo drejtimin përpara se të ndryshosh diçka në host. Nëse adresa e tunelit përgjigjet nga vetë porta, por jo nga një palë, ndryshimi është cilësimi klient-ndaj-klient i portës, dhe asnjë redaktim i firewall-it lokal nuk mund ta zëvendësojë atë.
Më në fund, gjej politikën që lejon rrjedhën
Tre shtresa politike qëndrojnë midis një pakete të drejtuar dhe një shërbimi që përgjigjet: vendimi i përcjelljes së serverit VPN, firewall-i i host-it dhe çdo grup sigurie i resë përpara instancës. Të tre duhet të bien dakord dhe dështojnë në mënyra të ndryshme, prandaj simptomi në tabelën më sipër është më i dobishëm se mesazhi i gabimit në shfletues.
Firewall-i i host-it është shtresa që njerëzit e harrojnë pas një lidhjeje të suksesshme, sepse një rregull që lejon portën në ndërfaqen LAN nuk e lejon automatikisht në ndërfaqen e tunelit. Rregullat e kufizuara në ndërfaqe janë ndërtim i saktë dhe njëkohësisht shkaku i zakonshëm i një shërbimi që punon nga zyra dhe jo nga shtëpia. Lexo shtrirjen e rregullit, jo numrin e portës.
Filtrimi me gjendje shpjegon rastin e kundërt. Një lidhje dalëse nga laptopi juaj krijon gjendje dhe përgjigjet ndaj saj pranohen pa një rregull hyrës. Lidhja e kolegut është një rrjedhë krejt e re pa gjendje pas saj, prandaj kërkon leje të shprehur. Kjo asimetri është i gjithë shkaku pse një sesion shfletuesi që punon në makinën tuaj nuk thotë asgjë nëse shërbimi arrihet nga jashtë.
Kur një kontroll dështon, ndrysho ndërtimin dhe jo tunelin
Nëse kërkesa është që një koleg të hapë shërbimin tuaj lokal, përgjigjja e ndershme është zakonisht një mekanizëm i ndërtuar për akses hyrës. Një tunel SSH i kundërt është më i vogli: makina juaj lidhet nga jashtë me një host që kolegu tashmë mund ta arrijë, dhe dëgjuesi ekziston në atë host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Releu ka nevojë për GatewayPorts clientspecified në konfigurimin e serverit SSH, përndryshe dëgjuesi i përcjellë lidhet me loopback në rele dhe kolegu përballet me të njëjtin refuzim si më parë. Për çdo gjë që zgjat më shumë se një pasdite, një balancues ngarkese ose ingress me kontroll shëndetësor dhe certifikatë për emrin e publikuar është instrumenti më i mirë, dhe një tunel nga vendndodhja në vendndodhje me rrugë për të dy nënrrjetet është përgjigjja e saktë kur dy rrjete vërtet duhet të flasin.
Secili prej këtyre ndërtimeve e bën ekspozimin të shprehur, dhe ky është qëllimi. Një VPN lëviz paketa midis rrjeteve për të cilat ishit tashmë i autorizuar; nuk publikon një shërbim dhe nuk e kthen një laptop në një host të kthyer nga interneti. Detyra është të vendosësh cilën nga tre shtresat të ndryshosh, dhe tuneli rrallë është një prej tyre.