Uživatel brány Access Server: směrování LAN pobočky klienta
V Access Serveru není adresa tunelu klienta cestou do jeho pobočky. Deklarujte uživatele brány a opravte obě zpětné cesty i předávání.
Můžete pingnout adresu tunelu klienta OpenVPN a přesto nedosáhnete žádného hostitele v LAN za ním. Access Server přidělí klientovi adresu z fondu VPN a adresa z fondu je vše, co server považuje za své. Prefix pobočky je samostatný údaj, který je třeba deklarovat, a i potom pobočka potřebuje přeposílající prvek a centrála zpětnou cestu. Trasa zapsaná na špatném místě vypadá jako řešení a nic nemění.
Dvě adresy, dva různé nároky na vlastnictví
Při připojení přidělí Access Server klientovi adresu z nakonfigurovaného fondu VPN, například 10.90.0.0/24. To je pronájem pro jednoho hostitele. Spojení neříká, že stejný klient stojí i před 10.60.0.0/24, a server nebude hádat: prefix LAN je přes konkrétního klienta dostupný jen tehdy, když to správce deklaruje.
Proto statická trasa na jiném stroji nefunguje. Trasa říká posílej 10.60.0.0/24 na tuto adresu, ale pokud adresa patří klientovi, který nebyl označen jako brána, server nemá důvod tam ty pakety doručovat a klientův stack je může zahodit. Deklarace a trasa jsou dvě poloviny jednoho mechanismu.
Co nastavení brány skutečně instaluje
V Admin Web UI je deklarace vlastností uživatele: zapněte Configure VPN gateway u uživatele konektoru a zadejte skutečný prefix pobočky do Network on the VPN client side. Tento uživatel se ověřuje jako každý jiný, takže potřebuje zásady přihlašovacích údajů pro zařízení bez dozoru a jeho profil automatického přihlášení je tajemství, ne soubor pohodlí.
Za tímto zaškrtávacím políčkem server považuje prefix za dostupný přes adresu z fondu daného klienta a konfigurace směrování v Access Controls určuje, co se oznámí ostatním klientům: trasy posílané běžným klientům a pravidla přístupu, která povolují provoz ze sítí centrály na adresy a podsítě klientů. Zapněte směrování pro sítě, které mají dosáhnout na pobočku, a seznam povolených sítí držte krátký.
Direktiva ve stylu Community vložená do generovaného souboru se tohoto modelu neúčastní. Produkt vlastní směrovací tabulku, kterou posílá; ručně upravený řádek se při příštím generování přepíše nebo se ignoruje.
Dokončete zpětné cesty obou sítí
Konkrétní plán: centrála 10.40.0.0/24, pobočka 10.60.0.0/24, fond VPN 10.90.0.0/24 a Access Server dostupný na privátní adrese na straně centrály. Router centrály potřebuje trasy pro prefix pobočky i pro fond, obě směrem k Access Serveru. Bez nich tunel nese požadavek a odpověď odchází přes výchozí bránu, což dává klasické polootevřené spojení.
V pobočce musí konektor předávat pakety, které nejsou adresovány jemu: IP forwarding v jeho operačním systému plus povolení předávání omezené na rozhraní tunelu a LAN; na Linuxu je to net.ipv4.ip_forward=1 spolu s pravidly řetězce forward, na Windows routing and remote access. Hostitelé v pobočce pak potřebují zpětnou cestu: buď je konektor jejich výchozí brána, nebo stávající brána nese specifické trasy pro prefixy centrály a fondu.
Vlastní směrovací tabulka konektoru nenastaví znovu každého hostitele v LAN pobočky. Pokud hostitelé ukazují na jiný router, zpětné trasy patří tam a ten router musí přijmout, že zdrojová adresa, kterou vidí, není sousedem v lokální podsíti.
Čtěte selhání jako cestu, ne jako oprávnění
Testujte v pevném pořadí. Nejprve povolená služba z Access Serveru na hostitele pobočky, poté stejná služba z běžného hostitele centrály, poté opačný směr, pokud to zásady dovolují. Pokud první projde a druhý ne, problémem jsou posílané trasy nebo pravidla přístupu. Pokud projdou oba a odpovědi nepřicházejí, zkontrolujte předávání v pobočce a zpětnou trasu v centrále.
Dalším podezřelým je firewall hostitele, protože při směrovaném přístupu vidí cíl jako zdroj adresu centrály nebo fondu. Pravidlo psané pro lokální podsíť nebude odpovídat a paket se zahodí poté, co směrování fungovalo bezchybně.
Dva návrhy potřebují víc. Překrývající se prefixy mezi lokalitami činí cíl nejednoznačným a vyžadují přečíslování nebo překlad a clusterovaný Access Server potřebuje, aby každý uzel měl funkční cestu ke konektoru pobočky, ne jeden uzel držící trasu. Změny aplikujte běžnou cestou uložení a aktualizace, znovu připojte konektor a ověřte z obou stran; úplný restart každého stroje není součástí postupu.
Návod Access Server pro spojení lokalita-lokalita uvádí stejná nastavení v pořadí produktu; stojí za to ho jednou projít, než návrh přizpůsobíte svým prefixům.