Proč adresa vašeho VPN tunelu neotevře příchozí port
Adresa tunelu identifikuje vašeho klienta vůči protějškům, které k ní umějí směrovat, a nikdy nevytvoří naslouchač. Zkontrolujte navázání, zpětnou trasu a potom politiku.
Připojte se k firemní VPN, spusťte malou službu na portu 8443, pošlete adresu tunelu kolegovi a sledujte, jak spojení selhává, zatímco klient stále hlásí, že je připojen. V tunelu není nic rozbité: adresa byla přidělena, relace běží a pakety, které by nesly odpověď, prostě nikdy neprojdou. Proveďte tři níže uvedené kontroly popořadě a zastavte se u té, která selže, protože každá má jinou opravu a jen jedna z nich se týká VPN.
Začněte tím, kam je socket skutečně navázán
Než se cokoli začne směrovat, musí něco naslouchat na adrese, kterou volající dosáhne. Vývojové servery bývají obvyklým viníkem, protože mnohé se ve výchozím nastavení navazují na loopback a přijímají jen spojení, která vznikají na stejném stroji. Adresa tunelu toto navázání nemění a operační systém spojení odmítne dávno předtím, než se VPN vůbec zapojí.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Čtěte sloupec místní adresy, ne stav. 127.0.0.1:8443 znamená jen loopback a opravou je navázání na 0.0.0.0 nebo přímo na adresu tunelu. 0.0.0.0:8443 přijímá na všech rozhraních, což je širší, než většina lidí zamýšlí, když má stroj i veřejnou adresu; 10.64.7.15:8443 je úzká verze, která naslouchá jen tam, kam se kolega dostane. Všimněte si i názvu procesu ve stejném výstupu, protože zbloudilá instance z dřívějšího testu bývá častou příčinou, že port vypadá otevřený a odpovídá špatným obsahem.
Pak se ptejte, zda k té adrese umí něco směrovat
Adresa tunelu má smysl jen pro protějšky nakonfigurované tak, aby tento prefix posílaly do tunelu. Kolegův stroj má vlastní tabulku, a pokud nemá trasu do podsítě tunelu, paket jde na výchozí bránu a zemře na místě, které o existenci adresy nemá tušení. To je otázka směrování na straně volajícího, ne oprávnění na vaší straně.
| 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 mezi oběma klienty je stejně důležitý. V obvyklém návrhu vzdáleného přístupu otevírá každý klient odchozí spojení k bráně a brána si drží stav těchto toků, takže odpovědi se vracejí cestou, kterou už zná. Spojení z jednoho klienta na druhého je nový tok, který brána musí přijmout a předat, a mnohá nasazení to záměrně vypínají, aby klienty udržela navzájem izolované. Spotřebitelské VPN služby obvykle izolují ve výchozím nastavení; podnikové brány to někdy povolují po skupinách.
Ověřte směr, než na hostiteli cokoli změníte. Pokud adresa tunelu odpovídá z brány samotné, ale ne od protějšku, rozdílem je nastavení brány klient-klient a žádné úpravy místního firewallu to nenahradí.
Nakonec najděte politiku, která tok povoluje
Mezi směrovaným paketem a službou, která odpovídá, stojí tři vrstvy politiky: rozhodnutí VPN serveru o předávání, firewall hostitele a jakákoli cloudová bezpečnostní skupina před instancí. Všechny tři musí souhlasit a selhávají různými způsoby, proto je symptom v tabulce výše užitečnější než chybová zpráva v prohlížeči.
Firewall hostitele je vrstva, na kterou lidé po úspěšném navázání zapomínají, protože pravidlo, které povoluje port na rozhraní LAN, jej automaticky nepovolí na rozhraní tunelu. Pravidla omezená na rozhraní jsou správný návrh a zároveň obvyklá příčina služby, která funguje z kanceláře a ne z domova. Čtěte rozsah pravidla, ne číslo portu.
Filtrování se stavem vysvětluje opačný případ. Odchozí spojení z vašeho notebooku vytvoří stav a odpovědi na něj procházejí bez příchozího pravidla. Kolegovo spojení je zcela nový tok bez stavu za sebou, takže potřebuje výslovné povolení. Tato asymetrie je celý důvod, proč funkční relace prohlížeče na vašem stroji nic neříká o tom, zda je služba dostupná zvenčí.
Když jedna kontrola selže, změňte návrh, ne tunel
Pokud je požadavkem, aby kolega otevřel vaši místní službu, poctivou odpovědí je obvykle mechanismus postavený pro příchozí přístup. Reverzní SSH tunel je nejmenší: váš stroj se odchozím spojením připojí k hostiteli, který kolega už dosáhne, a naslouchač existuje na onom hostiteli.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Přeposílač potřebuje GatewayPorts clientspecified ve své konfiguraci SSH serveru, jinak se předaný naslouchač naváže na loopback na přeposílači a kolega narazí na stejné odmítnutí jako předtím. Pro cokoli, co vydrží déle než odpoledne, je lepším nástrojem vyvažovač zátěže nebo ingress s kontrolou stavu a certifikátem pro zveřejněné jméno, a tunel mezi lokalitami s trasami pro obě podsítě je správná odpověď, když spolu dvě sítě opravdu potřebují mluvit.
Každý z těchto návrhů činí expozici explicitní, a o to jde. VPN přenáší pakety mezi sítěmi, které jste už směli používat; nepublikuje službu a nemění notebook v hostitele obráceného do internetu. Úkolem je rozhodnout, kterou ze tří vrstev změnit, a tunel mezi nimi bývá jen zřídka.