Proč jsou klienti Access Serveru nedostupní z LAN

Notebook se připojí, tunel běží a požadavky na interní službu visí při navazování spojení. Na samotné službě požadavek přichází z adresy jako 10.90.0.25, odpověď odchází k výchozí bráně a nic se nevrací, protože ta brána netuší, kde bydlí 10.90.0.25. Z druhého konce vypadá stejná závada jako interní hostitel, který nedokáže pingnout připojeného klienta. Obojí je jeden chybějící objekt: zpáteční trasa k poolu klientů VPN, kterou umí přidat jen privátní síť.

Přečtěte zdrojovou adresu, kterou služba vidí

To jediné pole rozhoduje o všem ostatním. Pokud interní služba vidí adresu z poolu, Access Server směruje, místo aby klientský provoz skrýval, a každá odpověď se musí směrovat zpět do poolu. Pokud místo toho vidí vlastní privátní adresu serveru, server maskuje a zpáteční cesta už funguje, ovšem za cenu ztráty jakékoli identity jednotlivého klienta v protokolech a přístupových pravidlech služby.

Porovnejte oba konce, než cokoli změníte. Na serveru vypište tunelová rozhraní a jejich adresy; na klientovi ověřte, kterou z těch adres skutečně drží; na interním hostiteli se podívejte na živé spojení.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Poslední příkaz je ten, který v rozbitém případě selže: buď ohlásí prefix tunelu jako nedostupný, nebo, což je horší, vrátí vaši výchozí bránu, a tak se odpovědi dostanou na internet.

Nepředpokládejte jediný pool. Server může mít dynamický rozsah plus statické přiřazení pro jednotlivé uživatele a statická adresa může ležet zcela mimo dynamický prefix. Pokud směrujete jen rozsah, který si pamatujete, uživatelé s pevnými adresami zůstanou rozbití a všichni ostatní hlásí, že je problém vyřešen.

Přidejte trasu tam, kde se rozhoduje o odpovědi

Trasa patří bráně, kterou interní služba už používá, ne službě samotné, pokud si tedy své vlastní provoz nesměruje sama. Namiřte ji na dostupnou privátní adresu Access Serveru, což je jiná hodnota než adresa tunelu, kterou drží klient.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

V cloudové síti se stejné tvrzení stane záznamem v tabulce tras, jehož cílem je instance nebo síťové rozhraní, na kterém server běží, s vypnutou kontrolou zdroje a cíle na tomto rozhraní. Všimněte si, co ten záznam nedělá: trasa není udělení přístupu, takže bezpečnostní skupiny, síťové ACL a hostitelský firewall musí provoz stále povolit.

Udělejte ji trvalou a držte velikosti poolů poctivé. Dva nesouvislé pooly potřebují dvě trasy a pool, který přeroste nakonfigurovaný prefix, tiše vytváří klienty, jejichž odpovědi nemají kam jít. Pokud rozsahy poolů řídíte, zvolte souhrn, který můžete nasměrovat jednou a nechat být.

Přeposílání a filtry musí s trasou souhlasit

Směrování je jen polovina cesty. Serveru musí být povoleno přeposílat mezi tunelem a privátním rozhraním, což na Linuxu znamená net.ipv4.ip_forward plus řetěz přeposílání, který povoluje dvojici rozhraní, a na ztvrzněném hostiteli obvykle výslovné pravidlo pro každý směr.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Filtrování se stavem vysvětluje příznak, který lidi zavádí na špatnou cestu. Odpověď uvnitř navázaného toku nepotřebuje nové příchozí pravidlo, takže spojení, které po SYN-ACK visí, není blokováno chybějícím pravidlem accept; je zahazováno nebo špatně směrováno. Tu distinkci si ponechte, protože odděluje změnu směrování od změny firewallu.

Asymetrické zpáteční cesty jsou tišší verzí téhož problému. Pokud se do poolu dostanou dvě trasy a odpověď se vydá tou, která vychází z jiného rozhraní, než na které požadavek dorazil, striktní filtrování zpětné cesty ji zahodí a tok selže jen u některých klientů.

Směrované, nebo maskované: vyberte vědomě

Směrovaný režim zachovává adresu klienta z poolu na službě, což umožňuje protokolování a politiku pro jednotlivé klienty, a výměnou každá interní síť, která musí klientovi odpovědět, potřebuje trasu poolu. Maskovaný režim tento požadavek odstraňuje, protože odpovědi se vracejí na server, ale služba už nerozliší jednoho klienta od druhého a nemůže vůči konkrétnímu klientovi nic iniciovat.

Změna tohoto chování na živém serveru shodí existující relace, proto nejdřív testujte s jedním klientem a jedním tokem. Pokud je přepnutí správná odpověď, je to rozhodnutí o konfiguraci serveru, ne něco, co se obchází přidáváním tras, které budou zbytečné.

Podsíť za klientem je samostatný úkol

Dosáhnout na zařízení ve vlastní LAN notebooku není totéž jako dosáhnout na adresu tunelu notebooku. Vyžaduje, aby klient vystupoval jako brána podsítě: deklarovaná síť na straně klienta, povolené přeposílání v operačním systému klienta a trasa v této LAN zpět ke klientovi. Přidání trasy privátní sítě pro domácí rozsah notebooku to neudělá a vytváří konflikty, když mají dva uživatelé stejný domácí rozsah.

Směr je také otázka politiky. Povolení, aby klient otevřel spojení k interní službě, automaticky neumožní internímu hostiteli otevřít spojení k tomuto klientovi. Zkontrolujte přístupovou politiku serveru a hostitelský firewall klienta, než dojdete k závěru, že je cesta rozbitá.

Ověřte jedním tokem a jedním odposlechem

Dokažte cestu jediným spojením místo obecného testu dostupnosti. Sledujte stejný tok na obou koncích: požadavek přicházející do služby a odpověď, která ji opouští.

tcpdump -ni any host 10.90.0.25 and port 443

Před opravou odposlech ukazuje odpověď odcházející k bráně, která ji nebude směrovat. Po opravě odpověď odchází k serveru a tok se dokončí. Pak ověřte trasu, kterou by brána použila pro adresu druhého klienta, aby se nepokrytý pool ukázal hned, ne za týden.

Uzavřete to čtyřmi kontrolami: zdrojová adresa na službě odpovídá režimu, který jste zamýšleli, brána má trasu ke každému používanému poolu, přeposílání a filtry povolují oba směry a jeden skutečný tok projde od začátku do konce. Časté dotazy ke směrování Access Serveru uvádí stejný princip pro nainstalované vydání, jehož podporované konfigurační rozhraní se může lišit od starších příruček.