Prečo adresa vášho VPN tunela neotvorí prichádzajúci port
Adresa tunela identifikuje vášho klienta voči partnerom, ktorí k nej vedia smerovať, a nikdy nevytvorí poslucháča. Skontrolujte naviazanie, spätnú trasu a potom politiku.
Pripojte sa k firemnej VPN, spustite malú službu na porte 8443, pošlite adresu tunela kolegovi a sledujte, ako spojenie zlyháva, zatiaľ čo klient stále hlási, že je pripojený. V tuneli nič nie je pokazené: adresa bola pridelená, relácia beží a pakety, ktoré by niesli odpoveď, sa jednoducho nikdy nepustia. Vykonajte tri kontroly nižšie v poradí a zastavte sa pri tej, ktorá zlyhá, pretože každá má inú opravu a iba jedna z nich sa týka VPN.
Začnite tým, kam je socket skutočne naviazaný
Skôr než sa čokoľvek začne smerovať, musí niečo počúvať na adrese, ktorú volajúci dosiahne. Vývojové servery bývajú obvyklým vinníkom, pretože mnohé sa predvolene viažu na loopback a prijímajú len spojenia, ktoré vznikajú na tom istom stroji. Adresa tunela toto naviazanie nemení a operačný systém spojenie odmietne dávno predtým, než sa VPN vôbec zapojí.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Čítajte stĺpec miestnej adresy, nie stav. 127.0.0.1:8443 znamená len loopback a opravou je naviazanie na 0.0.0.0 alebo priamo na adresu tunela. 0.0.0.0:8443 prijíma na všetkých rozhraniach, čo je širšie, než väčšina ľudí zamýšľa, keď má stroj aj verejnú adresu; 10.64.7.15:8443 je úzka verzia, ktorá počúva len tam, kam sa kolega dostane. Všimnite si aj názov procesu v tom istom výstupe, pretože zablúdená inštancia z predchádzajúceho testu býva častou príčinou, že port vyzerá otvorený a odpovedá nesprávnym obsahom.
Potom sa pýtajte, či k tej adrese vie niečo smerovať
Adresa tunela má zmysel len pre partnerov nakonfigurovaných tak, aby tento prefix posielali do tunela. Kolegov stroj má vlastnú tabuľku, a ak nemá trasu do podsiete tunela, paket ide na predvolenú bránu a zomrie na mieste, ktoré o existencii adresy nemá tušenie. To je otázka smerovania na strane volajúceho, nie povolenie na vašej strane.
| 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 medzi oboma klientmi je rovnako dôležitý. V obvyklom návrhu vzdialeného prístupu otvára každý klient odchádzajúce spojenie k bráne a brána si drží stav týchto tokov, takže odpovede sa vracajú cestou, ktorú už pozná. Spojenie z jedného klienta na druhého je nový tok, ktorý brána musí prijať a preposlať, a mnohé nasadenia to zámerne vypínajú, aby klientov udržali navzájom izolovaných. Spotrebiteľské VPN služby zvyčajne izolujú predvolene; podnikové brány to niekedy povoľujú po skupinách.
Overte smer, než na hostiteľovi čokoľvek zmeníte. Ak adresa tunela odpovedá z brány samotnej, ale nie od partnera, rozdielom je nastavenie brány klient-klient a žiadne úpravy miestneho firewallu to nenahradia.
Nakoniec nájdite politiku, ktorá tok povoľuje
Medzi smerovaným paketom a službou, ktorá odpovedá, stoja tri vrstvy politiky: rozhodnutie VPN servera o preposielaní, firewall hostiteľa a akákoľvek cloudová bezpečnostná skupina pred inštanciou. Všetky tri musia súhlasiť a zlyhávajú rôznymi spôsobmi, preto je príznak v tabuľke vyššie užitočnejší než chybové hlásenie v prehliadači.
Firewall hostiteľa je vrstva, na ktorú ľudia po úspešnom naviazaní zabúdajú, pretože pravidlo, ktoré povoľuje port na rozhraní LAN, ho automaticky nepovolí na rozhraní tunela. Pravidlá obmedzené na rozhranie sú správny dizajn a zároveň obvyklá príčina služby, ktorá funguje z kancelárie a nie z domu. Čítajte rozsah pravidla, nie číslo portu.
Filtrovanie so stavom vysvetľuje opačný prípad. Odchádzajúce spojenie z vášho notebooku vytvorí stav a odpovede naň prechádzajú bez prichádzajúceho pravidla. Kolegovo spojenie je úplne nový tok bez stavu za sebou, takže potrebuje výslovné povolenie. Táto asymetria je celý dôvod, prečo funkčná relácia prehliadača na vašom stroji nič nehovorí o tom, či je služba dostupná zvonku.
Keď jedna kontrola zlyhá, zmeňte dizajn, nie tunel
Ak je požiadavkou, aby kolega otvoril vašu miestnu službu, poctivou odpoveďou je zvyčajne mechanizmus postavený pre prichádzajúci prístup. Reverzný SSH tunel je najmenší: váš stroj sa odchádzajúcim spojením pripojí k hostiteľovi, ktorý kolega už dosiahne, a poslucháč existuje na tom hostiteľovi.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Preposielač potrebuje GatewayPorts clientspecified vo svojej konfigurácii SSH servera, inak sa preposlaný poslucháč naviaže na loopback na preposielači a kolega narazí na rovnaké odmietnutie ako predtým. Pre čokoľvek, čo vydrží dlhšie ako popoludnie, je lepším nástrojom vyvažovač záťaže alebo ingress s kontrolou stavu a certifikátom pre zverejnené meno, a tunel medzi lokalitami s trasami pre obe podsiete je správna odpoveď, keď dve siete naozaj potrebujú hovoriť.
Každý z týchto návrhov robí expozíciu explicitnou a o to ide. VPN prenáša pakety medzi sieťami, na ktoré ste už boli oprávnený; nepublikuje službu a nemení notebook na hostiteľa obráteného do internetu. Úlohou je rozhodnúť, ktorú z troch vrstiev zmeniť, a tunel medzi nimi býva len zriedka.