Miért nem érhetők el az Access Server kliensei a LAN-ból

A laptop csatlakozik, az alagút él, és a belső szolgáltatás felé menő kérések a kapcsolódásnál elakadnak. Magánál a szolgáltatásnál a kérés olyan címről érkezik, mint 10.90.0.25, a válasz az alapértelmezett átjáró felé indul, és semmi nem jön vissza, mert annak az átjárónak fogalma sincs, hol található 10.90.0.25. A másik oldalról ugyanez a hiba úgy néz ki, mint egy belső gazdagép, amely nem tud pingelni egy csatlakozott klienst. Mindkettő egyetlen hiányzó objektum: visszaút a VPN-kliens poolhoz, amelyet csak a privát hálózat tud hozzáadni.

Olvassa el a forráscímet, amelyet a szolgáltatás lát

Ez az egyetlen mező dönt minden másról. Ha a belső szolgáltatás a pool címét látja, az Access Server route-ol, nem pedig elrejti a kliensforgalmat, és minden választ vissza kell route-olni a poolhoz. Ha viszont a szerver saját privát címét látja, a szerver maszkol, és a válaszút már működik, annak árán, hogy elveszik minden kliensenkénti azonosítás a szolgáltatás naplóiból és hozzáférési szabályaiból.

Hasonlítsa össze mindkét végét, mielőtt bármit módosítana. A szerveren listázza az alagút-interfészeket és címeiket; a kliensen erősítse meg, melyik címet tartja valójában; a belső gazdagépen nézzen meg egy élő kapcsolatot.

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

Az utolsó parancs az, amely a hibás esetben elbukik: vagy elérhetetlennek jelenti az alagút előtagját, vagy, ami rosszabb, visszaadja az alapértelmezett átjárót, és így kerülnek a válaszok az internetre.

Ne feltételezzen egyetlen poolt. Egy szervernek lehet dinamikus tartománya, valamint felhasználónkénti statikus leképezései, és a statikus cím teljesen a dinamikus előtagon kívül eshet. Ha csak az emlékezetében élő tartományt route-olja, a fix című felhasználók hibásak maradnak, mindenki más pedig megoldottnak jelenti a problémát.

Adja hozzá az útvonalat ott, ahol a válasz eldől

Az útvonal ahhoz az átjáróhoz tartozik, amelyet a belső szolgáltatás már használ, nem a szolgáltatáshoz, kivéve, ha az maga route-olja a forgalmát. Mutasson rá az Access Server elérhető privát címére, amely különbözik a kliens alagútcímétől.

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

Felhőhálózatban ugyanez az állítás egy útvonaltábla-bejegyzés lesz, amelynek célja a szervert futtató példány vagy hálózati interfész, kikapcsolt forrás- és célellenőrzéssel azon az interfészen. Figyelje meg, mit nem tesz meg ez a bejegyzés: az útvonal nem hozzáférési engedély, ezért a biztonsági csoportoknak, a hálózati ACL-eknek és a gazdagép tűzfalának továbbra is engedélyeznie kell a forgalmat.

Tegye tartóssá, és tartsa őszintén a poolok méretét. Két nem összefüggő poolhoz két útvonal kell, és az a pool, amely túlnő a beállított előtagján, csendesen olyan klienseket hoz létre, amelyek válaszainak nincs hová menniük. Ha Ön irányítja a pooltartományokat, válasszon olyan összesítést, amelyet egyszer route-olhat, és aztán békén hagyhat.

A továbbításnak és a szűrőknek egyezniük kell az útvonallal

A route-olás csak az út fele. A szervernek engedélyezni kell a továbbítást az alagút és a privát interfész között, ami Linuxon net.ipv4.ip_forward plusz egy továbbítási láncot jelent, amely engedélyezi az interfészpárt, és egy megerősített gazdagépen általában külön szabályt mindkét irányra.

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

Az állapotkövető szűrés megmagyaráz egy tünetet, amely rossz útra viszi az embereket. Egy létrejött folyam válaszának nincs szüksége új bejövő szabályra, ezért a SYN-ACK után elakadó kapcsolatot nem egy hiányzó accept szabály blokkolja; eldobódik vagy rosszul route-olódik. Tartsa meg ezt a megkülönböztetést, mert elválasztja a route-olási változtatást a tűzfalszabály-változtatástól.

Az aszimmetrikus visszautak ugyanennek a problémának a halkabb változata. Ha két útvonal ér el a poolhoz, és a válasz azt választja, amely más interfészen lép ki, mint amelyiken a kérés érkezett, a szigorú visszaút-szűrés eldobja, és a folyam csak néhány kliensnél hiúsul meg.

Route-olt vagy maszkolt: válasszon megfontoltan

A route-olt mód megőrzi a kliens pool-címét a szolgáltatásnál, ami lehetővé teszi a kliensenkénti naplózást és házirendet, cserébe viszont minden belső hálózatnak, amelynek válaszolnia kell egy kliensnek, szüksége van a pool útvonalára. A maszkolt mód megszünteti ezt a követelményt, mert a válaszok visszatérnek a szerverhez, de a szolgáltatás már nem tudja megkülönböztetni az egyik klienst a másiktól, és nem tud semmit kezdeményezni egy adott kliens felé.

Ennek a viselkedésnek az élő szerveren való megváltoztatása megszakítja a meglévő munkameneteket, ezért először egy klienssel és egy folyammal teszteljen. Ha a váltás a helyes válasz, az a szerver konfigurációs döntése, nem olyasmi, amit plusz útvonalak hozzáadásával kerülnek meg, amelyek később feleslegessé válnak.

A kliens mögötti alhálózat külön feladat

Egy eszköz elérése a laptop saját LAN-ján nem ugyanaz, mint a laptop alagútcímének elérése. Ehhez a kliensnek alhálózati átjáróként kell működnie: deklarált kliens oldali hálózat, engedélyezett továbbítás a kliens operációs rendszerében, és egy útvonal azon a LAN-on vissza a kliens felé. A laptop otthoni tartományára vonatkozó priváthálózati útvonal hozzáadása ezt nem teszi meg, és ütközéseket okoz, ha két felhasználónak ugyanaz az otthoni tartománya.

Az irány is házirend-kérdés. Az engedély, hogy egy kliens kapcsolatot nyisson egy belső szolgáltatáshoz, nem engedi automatikusan, hogy egy belső gazdagép kapcsolatot nyisson ahhoz a klienshez. Ellenőrizze a szerver hozzáférési házirendjét és a kliens gazdagép-tűzfalát, mielőtt arra jutna, hogy az út hibás.

Ellenőrizze egy folyammal és egy rögzítéssel

Bizonyítsa az utat egyetlen kapcsolattal egy általános elérhetőségi teszt helyett. Figyelje ugyanazt a folyamot mindkét végén: a szolgáltatáshoz érkező kérést és az azt elhagyó választ.

tcpdump -ni any host 10.90.0.25 and port 443

A javítás előtt a rögzítés azt mutatja, hogy a válasz egy olyan átjáró felé indul, amely nem fogja route-olni. A javítás után a válasz a szerver felé indul, és a folyam befejeződik. Ezután erősítse meg az útvonalat, amelyet az átjáró egy második klienscímhez használna, hogy egy nem lefedett pool most derüljön ki, ne egy hét múlva.

Zárja a négy ellenőrzéssel, amelyek lezárják a témát: a szolgáltatásnál látott forráscím megfelel a szándékolt módnak, az átjárónak minden használt poolhoz van útvonala, a továbbítás és a szűrők mindkét irányt engedélyezik, és egy valódi folyam elejétől végéig lefut. Az Access Server route-olásának gyakori kérdései ugyanezt az elvet mondja ki a telepített kiadásra, amelynek támogatott konfigurációs felülete eltérhet a régebbi útmutatóktól.