Může roamingový VPN klient hostovat službu pro kancelář?

Roamingový klient může obsluhovat kancelářské systémy jen tehdy, když k němu brána směruje, hostitelská politika to dovoluje a zařízení zůstane dostatečně dlouho dostupné.

Váš kancelářský notebook se může připojit z domova a přesto poskytovat něco, co kancelář potřebuje, ale jen když se sejdou tři samostatná rozhodnutí. Tunel je přeprava, vnitřní adresa je cíl a politika rozhoduje, kdo smí zaklepat. Pokud kterékoli z nich považujete za celou odpověď, dostanete známou stížnost: hostitel odpovídá na pingy, ale aplikace se nikdy nepřipojí. Role nejsou stejné a rozdíl je přesně tam, kde leží návrhářská práce.

Směr připojování neříká nic o směru služby

Když klient spustí tunel, otevře cestu, kterou po jejím vzniku mohou používat oba směry. Zda nové spojení smí vstoupit z hubu směrem k tomuto klientovi, je otázka politiky brány, nikoli vlastnost toho, kdo se připojil. Například na směrovaném hubu OpenVPN server potřebuje trasu k vnitřní adrese klienta a předávání, které povoluje vztah peerů.

Představte si inventární systém, který dotazuje agenta na roamingových noteboocích, nebo vývojáře, který potřebuje testovací API z pracovní stanice doma. Oba chtějí, aby rozhovor začala kancelářská strana, což je opak obvyklého vzorce klient-server.

Hostované produkty pro vzdálený přístup se zde liší a ta odlišnost není chyba. Některé spravované VPN záměrně blokují nevyžádaná spojení směrem k připojeným klientům, protože jejich model je klient-k-zdroji, nikoli zdroj-ke-klientovi. Přečtěte si dokumentovanou architekturu produktu, než kolegovi slíbíte, že jeho notebook může fungovat jako server.

Sledujte cestu odpovědi, než otevřete port

Cesta má tři části: trasu na bráně, která ukazuje na vnitřní adresu klienta, politiku, která povoluje konkrétního volajícího, a naslouchající službu na cíli. Každá část selhává jinak, a proto „VPN běží“ neříká téměř nic.

Dobrá zpráva je, že vnitřní cesta nepotřebuje přesměrování portu na domácím routeru klienta. Právě o to jde při publikování služby na adrese tunelu místo na domácí WAN adrese, kde by expozice a pravidla NAT byla zcela jiná. Domácí router může také odmítnout hairpin spojení přicházejícího z kanceláře, takže WAN trasa selže z důvodů nesouvisejících s vaší VPN. Ponechání provozu uvnitř tunelu se vyhne oběma problémům najednou.

Zkontrolujte i stranu cíle. Služba vázaná pouze na 127.0.0.1 nemůže přijmout spojení přicházející na rozhraní tunelu, ať jsou trasy brány sebelepší. Pravidlo hostitelského firewallu, které povoluje port jen z lokální podsítě, také zahodí kancelářský provoz, a toto pravidlo je nezávislé na politice VPN nad ním.

Jména a adresy jsou rozhodnutí návrhu

Adresa uvnitř tunelu není automaticky jméno. Soukromý DNS záznam, který ovládáte, je jasnější než doufat, že protokol pro objevování projde tunelem, protože link-local multicastové překládání jmen zůstává v lokálním segmentu a nestává se DNS mezi podsítěmi.

Stabilita adresy je stejně důležitá. Pokud si VPN klienti berou adresy z poolu s krátkým pronájmem, vnitřní adresa notebooku se mezi relacemi mění a každá záložka, rozsah firewallu i monitorovací kontrola na ní postavená se tiše rozbije. Použijte rezervaci nebo dokumentovanou cestu dynamické aktualizace.

Dohodněte jméno s tím, kdo vlastní identitu VPN, aby se záznam, přidělení adresy a přístupová politika měnily společně, a ne ve třech samostatných tiketech.

Testujte službu, ne členství

Na cíli ověřte, co naslouchá a na které adrese, poté ověřte pohled brány na zpáteční cestu:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Nyní testujte z kancelářské strany skutečným požadavkem, ne ozvěnou. Úspěšný curl proti službě prokáže trasu, politiku i naslouchající proces najednou, zatímco úspěšný ping prokáže jen to, že je povolen ICMP. Pokud požadavek selže, jděte zpět přes tři části, místo abyste rozšiřovali firewall a doufali.

Dostupnost patří do stejného rozhovoru. Notebook spí, roamuje mezi sítěmi a na konci dne se odpojí. Služba, která musí odpovídat v kteroukoli hodinu, patří na stále zapnutý hostitel, zatímco služba s nejlepší snahou může zůstat na klientovi s tímto omezením zapsaným.

Publikujte zdroj záměrně — s jménem, seznamem povolených volajících a vlastníkem — a vzdálené zařízení se stane podporovanou službou, nikoli náhodným serverem.

Související články