Vzdálený přístup, nebo VPN site-to-site: co se hodí?

Cestující zaměstnanec a pobočka potřebují různé tunely a špatná volba dá návrh, který funguje v laboratoři a v první pondělí selže. Vzdálený přístup spojuje zařízení s bránou. Site-to-site spojuje dvě brány, které představují sítě. Kontrolní seznam níže rozhodne, který z nich požadavek vlastně popisuje.

Kdo vytáčí spojení a co stojí za volajícím

Při vzdáleném přístupu tunel sestavuje software v notebooku nebo telefonu a brána před přidělením adresy a tras ověří uživatele, zařízení, nebo obojí. Při site-to-site spojení navazují routery, firewally nebo cloudové brány a zařízení za nimi používají běžné směrování místo klientského programu. Tento rozdíl určuje, kdo odpovídá za dostupnost tunelu: zařízení zaměstnance v prvním případě, spravovaný přístroj ve druhém. Určuje také, zda ověření popisuje osobu, nebo síť.

Zastavte se zde, pokud požadavek zní, že každý stroj v jedné kanceláři má dosáhnout na jinou kancelář bez nastavení pro každé zařízení. To je site-to-site a hromada vzdálených přihlášení je slabá náhrada.

Adresování a zpáteční cesta

Naplánujte oddělené místní a vzdálené rozsahy. Dvě lokality mohou používat stejnou privátní podsíť a návrh pak před jednoznačným směrováním potřebuje překlad nebo přečíslování. Domácí router se stejným rozsahem jako centrála vytváří stejný problém pro jednoho vzdáleného pracovníka. Překryv je dost běžný na to, aby jeho kontrola patřila do prvního rozhovoru.

Zpáteční cesta je stejně důležitá jako odchozí. Server může přijmout požadavek a přesto nemít trasu zpět do klientské sítě.

Zaznamenejte, který router zná vzdálený prefix, zejména u cloudových sítí a několika bran. Zelená ikona tunelu nedokáže odpovědět, zda má cíl funkční zpáteční trasu, a ping jedním směrem také ne. Při vzdáleném přístupu obvykle trasu poolu vlastní brána; při site-to-site se musí shodnout každý mezilehlý router, který prefix nese. Překlad může chybějící trasu skrývat, dokud se nerozbije aplikace, která adresy vkládá.

Výstup do internetu je samostatné rozhodnutí

Privátní dostupnost nevyžaduje, aby tunel přenášel veřejné prohlížení. Zda běžný webový provoz vychází přes bránu, je druhé rozhodnutí, přijaté pro každý návrh a zaznamenané v profilu klienta nebo v konfiguraci lokality.

Plný a rozdělený tunel odpovídají na tuto otázku, ne na otázku vzdálený přístup versus site-to-site. Interní názvy potřebují v obou návrzích vhodný DNS, protože veřejný resolver nemá odpověď na název hostitele privátní kanceláře. Posílat resolver a posílat výchozí trasu jsou související nastavení a změna jednoho bez druhého dává poruchy, které vypadají jako problémy s DNS.

Použijte topologii k zúžení závady

Jeden putující notebook ztrácí přístup u klienta, svého účtu nebo své místní sítě. Celá pobočka ztrácí přístup na sdílených cestách a branách.

Zkontrolujte nejprve sestavení tunelu, potom trasy, potom povolený provoz, potom překlad názvů, potom přihlášení aplikace a zastavte se u prvního kroku, který selže.ip route get 10.60.8.15 odpovídá na otázku směrování dřív, než přečtete jediný log aplikace. Nastavení šifrování neopraví chybu oprávnění ke sdílenému souboru a funkční ping nedokazuje, že aplikace je autorizovaná. Dodržení pořadí brání náhodným změnám konfigurace, které z jedné závady udělají tři.

Nakonec držte definice rovné, když čtete materiály dodavatele: komerční server pro výstup do internetu je jiná služba než privátní brána firmy a neposkytuje žádný přístup do sítě této firmy.