Zašto adresa vašeg VPN tunela ne otvara ulazni port
Adresa tunela identificira vašeg klijenta prema partnerima koji mogu usmjeriti do nje i nikada ne stvara slušatelja. Provjerite vezivanje, povratnu rutu, pa politiku.
Povežite se na uredski VPN, pokrenite malu uslugu na portu 8443, pošaljite adresu tunela kolegi i gledajte kako veza pada dok klijent i dalje javlja da je povezan. Ništa u tunelu nije pokvareno: adresa je dodijeljena, sesija je aktivna, a paketi koji bi nosili odgovor jednostavno nikada nisu propušteni. Provedite tri provjere u nastavku redom i zaustavite se na onoj koja padne, jer svaka ima drugačiji popravak i samo se jedna od njih tiče VPN-a.
Počnite od toga gdje je socket zapravo vezan
Prije nego što se bilo što usmjeri, nešto mora slušati na adresi do koje pozivatelj može doći. Razvojni poslužitelji uobičajeni su krivac, jer se mnogi od njih prema zadanim postavkama vežu na loopback i prihvaćaju samo veze koje potječu s istog stroja. Adresa tunela ne mijenja to vezivanje, a operacijski sustav odbit će vezu mnogo prije nego što VPN uopće bude uključen.
ss -ltnp | grep 8443
netstat -ano | findstr 8443
Čitajte stupac lokalne adrese, a ne stanje. 127.0.0.1:8443 znači samo loopback, a popravak je vezivanje na 0.0.0.0 ili na samu adresu tunela. 0.0.0.0:8443 prihvaća na svim sučeljima, što je šire nego što većina ljudi namjerava kada stroj ima i javnu adresu; 10.64.7.15:8443 uska je verzija koja sluša samo tamo gdje kolega može doći. Obratite pozornost i na naziv procesa u istom izlazu, jer je zalutala instanca iz ranijeg testa čest razlog zašto port izgleda otvoren i odgovara pogrešnim sadržajem.
Zatim pitajte može li išta usmjeriti do te adrese
Adresa tunela ima smisla samo za partnere konfigurirane da taj prefiks šalju u tunel. Kolegino računalo ima vlastitu tablicu i, ako nema rutu za podmrežu tunela, paket odlazi na zadani pristupnik i umire na mjestu koje nema pojma da adresa postoji. To je pitanje usmjeravanja na strani pozivatelja, a ne dopuštenje na vašoj strani.
| 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 |
Poslužitelj između dva klijenta jednako je važan. U uobičajenom dizajnu daljinskog pristupa svaki klijent otvara odlaznu vezu prema pristupniku i pristupnik drži stanje tih tokova, pa se odgovori vraćaju putem koji već poznaje. Veza od jednog klijenta do drugog novi je tok koji pristupnik mora prihvatiti i proslijediti, a mnoga postavljanja to namjerno isključuju kako bi klijente držala izoliranima jedne od drugih. Potrošačke VPN usluge obično izoliraju prema zadanim postavkama; korporativni pristupnici to ponekad dopuštaju po grupi.
Provjerite smjer prije nego što bilo što promijenite na hostu. Ako adresa tunela odgovara s pristupnika samog ali ne od partnera, razlika je u postavci pristupnika za klijent-na-klijent i nikakvo uređivanje lokalnog vatrozida to ne može zamijeniti.
Na kraju, pronađite politiku koja dopušta tok
Tri sloja politike stoje između usmjerenog paketa i usluge koja odgovara: odluka VPN poslužitelja o prosljeđivanju, vatrozid hosta i bilo koja cloud sigurnosna grupa ispred instance. Sva tri moraju biti suglasna i padaju na različite načine, zato je simptom iz tablice iznad korisniji od poruke o pogrešci u pregledniku.
Vatrozid hosta je sloj koji ljudi zaborave nakon uspješnog vezivanja, jer pravilo koje dopušta port na LAN sučelju ne dopušta ga automatski na sučelju tunela. Pravila ograničena na sučelje ispravan su dizajn i ujedno uobičajen uzrok usluge koja radi iz ureda, ali ne od kuće. Čitajte opseg pravila, a ne broj porta.
Filtriranje sa stanjem objašnjava obrnut slučaj. Odlazna veza s vašeg prijenosnika stvara stanje i odgovori na nju propuštaju se bez ulaznog pravila. Kolegina veza posve je novi tok bez stanja iza sebe, pa joj treba izričito dopuštenje. Ta asimetrija cijeli je razlog zašto radna sesija preglednika na vašem računalu ne govori ništa o tome je li usluga dostupna izvana.
Kada jedna provjera padne, promijenite dizajn, a ne tunel
Ako je zahtjev da kolega otvori vašu lokalnu uslugu, iskren odgovor obično je mehanizam napravljen za ulazni pristup. Obrnuti SSH tunel najmanji je: vaše se računalo odlazno povezuje na host do kojeg kolega već može doći, a slušatelj postoji na tom hostu.
ssh -N -R 8443:127.0.0.1:8443 [email protected]
Posrednik zahtijeva GatewayPorts clientspecified u konfiguraciji svog SSH poslužitelja, inače se proslijeđeni slušatelj veže na loopback na posredniku i kolega nailazi na isto odbijanje kao prije. Za sve što traje dulje od jednog poslijepodneva, balanser opterećenja ili ingress s provjerom zdravlja i certifikatom za objavljeno ime bolji je alat, a tunel od lokacije do lokacije s rutama za obje podmreže pravi je odgovor kada dvije mreže doista trebaju razgovarati.
Svaki od tih dizajna čini izloženost eksplicitnom, i to je poanta. VPN prenosi pakete između mreža za koje ste već bili ovlašteni; on ne objavljuje uslugu i ne pretvara prijenosnik u host okrenut internetu. Odlučiti koji od tri sloja promijeniti je zadatak, a tunel je rijetko jedan od njih.