Zašto adresa vašeg VPN tunela ne otvara ulazni port
Adresa tunela identifikuje vašeg klijenta prema partnerima koji mogu usmjeriti do nje i nikada ne stvara slušaoca. 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 prijavljuje 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. Izvedite tri provjere ispod po redu i zaustavite se na onoj koja padne, jer svaka ima drugačiji popravak i samo jedna od njih se tiče VPN-a.
Počnite od toga gdje je soket zapravo vezan
Prije nego što bilo šta bude usmjereno, nešto mora slušati na adresi do koje pozivalac može doći. Razvojni serveri su uobičajeni krivac, jer se mnogi od njih podrazumijevano vežu na loopback i prihvataju samo veze koje potiču s istog računara. Adresa tunela ne mijenja to vezivanje i operativni sistem će odbiti vezu mnogo prije nego što VPN uopšte bude uključen.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Čitajte kolonu 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 prihvata na svim interfejsima, što je šire nego što većina ljudi namjerava kada računar ima i javnu adresu; 10.64.7.15:8443 je uska verzija koja sluša samo tamo gdje kolega može doći. Obratite pažnju 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 konfigurisane da taj prefiks šalju u tunel. Kolegin računar ima sopstvenu tabelu i, ako nema rutu za podmrežu tunela, paket odlazi na podrazumijevani gateway i umire na mjestu koje nema pojma da adresa postoji. To je pitanje rutiranja na strani pozivaoca, a ne dozvola 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 |
Server između dva klijenta je jednako važan. U uobičajenom dizajnu za daljinski pristup svaki klijent otvara odlaznu vezu prema gatewayu i gateway drži stanje tih tokova, pa se odgovori vraćaju putem koji već poznaje. Veza od jednog klijenta do drugog je novi tok koji gateway mora prihvatiti i proslijediti, a mnoga postavljanja to namjerno isključuju da bi klijente držali izolovanim jedne od drugih. Potrošačke VPN usluge obično izoluju podrazumijevano; korporativni gatewayi to ponekad dozvoljavaju po grupi.
Provjerite smjer prije nego što bilo šta promijenite na hostu. Ako adresa tunela odgovara sa samog gatewaya ali ne od partnera, razlika je u postavci gatewaya za klijent-na-klijent i nikakvo uređivanje lokalnog firewall-a to ne može zamijeniti.
Na kraju, pronađite politiku koja dozvoljava tok
Tri sloja politike stoje između usmjerenog paketa i usluge koja odgovara: odluka VPN servera o prosljeđivanju, firewall hosta i bilo koja cloud sigurnosna grupa ispred instance. Sva tri moraju biti saglasna i padaju na različite načine, zato je simptom iz tabele iznad korisniji od poruke o grešci u pregledaču.
Firewall hosta je sloj koji ljudi zaborave nakon uspješnog vezivanja, jer pravilo koje dozvoljava port na LAN interfejsu ne dozvoljava ga automatski na interfejsu tunela. Pravila ograničena na interfejs su ispravan dizajn i ujedno uobičajen uzrok usluge koja radi iz ureda, ali ne od kuće. Čitajte obim pravila, a ne broj porta.
Filtriranje sa stanjem objašnjava obrnut slučaj. Odlazna veza s vašeg laptopa stvara stanje i odgovori na nju se propuštaju bez ulaznog pravila. Kolegina veza je potpuno novi tok bez stanja iza sebe, pa joj treba izričita dozvola. Ta asimetrija je cijeli razlog zašto radna sesija pregledača na vašem računaru ne govori ništa o tome da li je usluga dostupna spolja.
Kada jedna provjera padne, promijenite dizajn, a ne tunel
Ako je zahtjev da kolega otvori vašu lokalnu uslugu, iskren odgovor je obično mehanizam napravljen za ulazni pristup. Obrnuti SSH tunel je najmanji: vaš računar se odlazno povezuje na host do kojeg kolega već može doći, a slušalac postoji na tom hostu.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relej zahtijeva GatewayPorts clientspecified u konfiguraciji svog SSH servera, inače se proslijeđeni slušalac veže na loopback na releju i kolega nailazi na isto odbijanje kao prije. Za sve što traje duže od jednog popodneva, balanser opterećenja ili ingress sa zdravstvenom provjerom i certifikatom za objavljeno ime je bolji alat, a tunel od lokacije do lokacije s rutama za obje podmreže je pravi odgovor kada dvije mreže zaista treba da razgovaraju.
Svaki od tih dizajna čini izloženost eksplicitnom, i to je poenta. VPN prenosi pakete između mreža koje su vam već bile dozvoljene; on ne objavljuje uslugu i ne pretvara laptop u host okrenut internetu. Odlučiti koji od tri sloja promijeniti je zadatak, a tunel je rijetko jedan od njih.