Notebook sa pripojí, tunel beží a požiadavky na internú službu visia pri nadväzovaní spojenia. Na samotnej službe požiadavka prichádza z adresy ako 10.90.0.25, odpoveď odchádza k predvolenej bráne a nič sa nevracia, pretože tá brána netuší, kde sa nachádza 10.90.0.25. Z druhého konca vyzerá tá istá porucha ako interný hostiteľ, ktorý nedokáže pingnúť pripojeného klienta. Obe sú jeden chýbajúci objekt: spätná trasa k poolu klientov VPN, ktorú dokáže pridať len privátna sieť.

Prečítajte zdrojovú adresu, ktorú služba vidí

To jediné pole rozhoduje o všetkom ostatnom. Ak interná služba vidí adresu poolu, Access Server smeruje namiesto toho, aby skrýval klientsku prevádzku, a každá odpoveď sa musí smerovať späť do poolu. Ak namiesto toho vidí vlastnú privátnu adresu servera, server maskuje a spätná cesta už funguje, ale za cenu straty akejkoľvek identity jednotlivého klienta v logoch a prístupových pravidlách služby.

Porovnajte oba konce, kým čokoľvek zmeníte. Na serveri vypíšte tunelové rozhrania a ich adresy; na klientovi overte, ktorú z tých adries skutočne drží; na internom hostiteľovi sa pozrite na živé spojenie.

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

Posledný príkaz je ten, ktorý v pokazenom prípade zlyhá: buď ohlási prefix tunela ako nedostupný, alebo, čo je horšie, vráti vašu predvolenú bránu, a tak sa odpovede dostanú na internet.

Nepredpokladajte jediný pool. Server môže mať dynamický rozsah plus statické priradenia pre jednotlivých používateľov a statická adresa môže ležať úplne mimo dynamického prefixu. Ak smerujete len rozsah, ktorý si pamätáte, používatelia s pevnými adresami zostanú pokazení a všetci ostatní hlásia, že problém je vyriešený.

Pridajte trasu tam, kde sa rozhoduje o odpovedi

Trasa patrí bráne, ktorú interná služba už používa, nie službe, ak si teda sama nesmeruje svoju prevádzku. Namieste ju na dostupnú privátnu adresu Access Serveru, ktorá je iná hodnota než adresa tunela, ktorú má klient.

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

V cloudovej sieti sa to isté tvrdenie stane záznamom v tabuľke trás, ktorého cieľom je inštancia alebo sieťové rozhranie, na ktorom server beží, s vypnutou kontrolou zdroja a cieľa na tomto rozhraní. Všimnite si, čo ten záznam nerobí: trasa nie je udelenie prístupu, takže bezpečnostné skupiny, sieťové ACL a hostiteľský firewall musia prevádzku stále povoľovať.

Urobte ju trvalou a držte veľkosti poolov čestné. Dva nesúvislé pooly potrebujú dve trasy a pool, ktorý prerastie nakonfigurovaný prefix, ticho vytvára klientov, ktorých odpovede nemajú kam ísť. Ak rozsahy poolov riadite, vyberte súhrn, ktorý môžete nasmerovať raz a nechať tak.

Preposielanie a filtre musia súhlasiť s trasou

Smerovanie je len polovica cesty. Serveru musí byť povolené preposielať medzi tunelom a privátnym rozhraním, čo na Linuxe znamená net.ipv4.ip_forward plus reťaz preposielania, ktorý povoľuje dvojicu rozhraní, a na spevnenom hostiteľovi zvyčajne výslovné pravidlo pre každý smer.

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

Filtrovanie so stavom vysvetľuje príznak, ktorý ľudí zvádza na nesprávnu cestu. Odpoveď v rámci nadviazaného toku nepotrebuje nové prichádzajúce pravidlo, takže spojenie, ktoré po SYN-ACK visí, nie je blokované chýbajúcim pravidlom accept; je zahadzované alebo nesprávne smerované. Zachovajte ten rozdiel, pretože oddeľuje zmenu smerovania od zmeny firewallu.

Asymetrické spätné cesty sú tichšou verziou toho istého problému. Ak sa do poolu dostanú dve trasy a odpoveď si vyberie tú, ktorá vychádza z iného rozhrania, než na ktoré požiadavka prišla, striktné filtrovanie spätnej cesty ju zahodí a tok zlyhá len u niektorých klientov.

Smerovaný alebo maskovaný: vyberte vedome

Smerovaný režim zachováva adresu klienta z poolu na službe, čo umožňuje logovanie a politiku pre jednotlivých klientov, a výmenou za to každá interná sieť, ktorá musí klientovi odpovedať, potrebuje trasu poolu. Maskovaný režim tento predpoklad odstraňuje, pretože odpovede sa vracajú na server, ale služba už nedokáže rozlíšiť jedného klienta od druhého a nemôže voči konkrétnemu klientovi nič iniciovať.

Zmena tohto správania na živom serveri zhodí existujúce relácie, preto najprv testujte s jedným klientom a jedným tokom. Ak je prepnutie správna odpoveď, je to rozhodnutie o konfigurácii na serveri, nie niečo, čo sa obchádza pridávaním trás, ktoré sa stanú zbytočnými.

Podsieť za klientom je samostatná úloha

Dosiahnuť zariadenie vo vlastnej LAN notebooku nie je to isté ako dosiahnuť adresu tunela notebooku. Vyžaduje, aby klient vystupoval ako brána podsiete: deklarovaná sieť na strane klienta, povolené preposielanie v operačnom systéme klienta a trasa v tejto LAN späť ku klientovi. Pridanie trasy privátnej siete pre domáci rozsah notebooku to neurobí a vytvára konflikty, keď majú dvaja používatelia rovnaký domáci rozsah.

Smer je tiež otázka politiky. Povolenie, aby klient otvoril spojenie k internej službe, automaticky neumožňuje internému hostiteľovi otvoriť spojenie k tomuto klientovi. Skontrolujte prístupovú politiku servera a hostiteľský firewall klienta, kým dospejete k záveru, že cesta je pokazená.

Overte jediným tokom a jediným odposluchom

Dokážte cestu jediným spojením namiesto všeobecného testu dostupnosti. Sledujte ten istý tok na oboch koncoch: požiadavku prichádzajúcu do služby a odpoveď, ktorá ju opúšťa.

tcpdump -ni any host 10.90.0.25 and port 443

Pred opravou odposluch ukazuje odpoveď odchádzajúcu k bráne, ktorá ju nebude smerovať. Po oprave odpoveď odchádza k serveru a tok sa dokončí. Potom overte trasu, ktorú by brána použila pre adresu druhého klienta, aby sa nepokrytý pool ukázal teraz a nie o týždeň.

Ukončite to štyrmi kontrolami: zdrojová adresa na službe zodpovedá zamýšľanému režimu, brána má trasu ku každému používanému poolu, preposielanie a filtre povoľujú oba smery a jeden skutočný tok prejde od začiatku do konca. Časté otázky k smerovaniu Access Serveru uvádza rovnaký princíp pre nainštalované vydanie, ktorého podporované konfiguračné rozhranie sa môže líšiť od starších príručiek.

Súvisiace články