LAN za jednou reláciou AWS Client VPN: čo sa preposiela

Notebook sa pripojí ku koncovému bodu AWS Client VPN, dosiahne privátnu podsiete a všetko vyzerá zdravo. Stolový počítač v tej istej LAN nedosiahne na nič, hoci hostiteľ Linux má tiež mostíkové rozhranie a oba stroje sú na tom istom kábli. V tuneli nie je nič zle nastavené; chýbajúcim dielom je smerovanie a most je falošná stopa.

Rozšírenie relácie Client VPN na LAN je rola brány. Nie je to Ethernetový segment natiahnutý do spravovanej služby.

Hostiteľ funguje a LAN nie

Tunelové rozhranie na linuxovom stroji má adresu v CIDR klienta Client VPN a koncový bod vložil trasy pre rozsahy VPC. Požiadavka z tohto stroja je lokálne generovaná prevádzka: vyberie trasu, odíde tunelom a dostane odpoveď. Táto cesta sa nikdy nedotkne kódu preposielania, rozhrania LAN ani žiadneho pravidla firewallu, ktoré riadi tranzit.

Prevádzka z iného zariadenia v LAN je iný tok. Dorazí na rozhranie LAN, potrebuje trasu ukazujúcu do tunela, potrebuje zapnuté preposielanie, potrebuje firewall, ktorý ju povolí, a potrebuje, aby sa odpoveď vrátila tým istým hostiteľom. Štyri požiadavky a funkčný test na notebooku nepreukazuje ani jednu. Zo stolového počítača vyzerá porucha zvláštne: tunel je hore, prihlasovacie údaje platia a cieľ jednoducho nikdy neodpovie. Porucha je lokálna v ceste preposielania brány, nie v službe.

Nie každý klient môže byť brána

AWS uvádza, že jeho desktopová aplikácia Client VPN nepodporuje preposielanie IP a že iní klienti môžu. Toto obmedzenie rozhoduje o architektúre skôr, než je napísaný akýkoľvek príkaz. Ak je jediným dostupným klientom oficiálna desktopová aplikácia, linuxová brána preposielajúca pre LAN nie je konfigurácia, ktorú možno dokončiť, a žiadne množstvo maskovania to nezmení.

Náhradný klient musí tiež zodpovedať metóde overovania koncového bodu a politike, ktorú chcete presadzovať. Koncové body založené na certifikátoch, adresári a SAML neprijímajú rovnaké konfigurácie klienta a klientska aplikácia tretej strany, ktorá sa overí, ale ignoruje vložené trasy, nie je zlepšením.

Berte voľbu klienta ako súčasť revízie návrhu. Určuje, či je vzor preposielania LAN vôbec dostupný, a určuje, akú identitu koncový bod vidí pre každé zariadenie za bránou. Zaznamenajte klienta a konfiguráciu koncového bodu, proti ktorej bol testovaný. Výmena klienta o pol roka môže ticho odstrániť schopnosť, ktorú návrh predpokladal.

Nasmerujte LAN do tunela a preložte ju

S podporovaným klientom na mieste je zvyšok bežná práca brány. Zariadenia LAN potrebujú trasu pre rozsah VPC ukazujúcu na hostiteľa Linux a hostiteľ potrebuje zapnuté preposielanie. Ak chcete, aby VPC videla prevádzku ako pripojeného klienta a nie ako ľubovoľnú adresu LAN, preložte zdroj na ceste von.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Obmedzte pravidlo na tunelové rozhranie a rozsah VPC, ako je uvedené vyššie, namiesto maskovania všetkého, čo hostiteľ preposiela. Užšie pravidlo sa ľahšie zdôvodňuje a ticho nemení prevádzku, ktorá mala zachovať pôvodnú zdrojovú adresu.

Nechajte trasu LAN prichádzať automaticky, ak môžete: voľba DHCP, oznámenie smerovača alebo statická trasa vložená tým, čo LAN spravuje. Trasa, ktorá existuje len na jednom testovacom stroji, spôsobí, že návrh bude vyzerať pokazený v okamihu, keď to skúsi niekto iný.

Odpoveď tiež potrebuje cestu

Keď požiadavka dorazí do VPC, odpoveď sa musí vrátiť cez rovnaké stavy prekladu a nájsť trasu LAN na bráne. Táto časť zvyčajne funguje, keď je pravidlo maskovania na mieste, pretože mapovanie žije na hostiteľovi, ktorý ho vykonal. Zlyhá, keď na strane VPC existuje trasa, ktorá odpoveď pošle inam; preto sú dôležité tak trasa CIDR klienta, ako aj priradenie podsiete na koncovom bode.

Sledujte počítadlá, nielen ping. Pravidlo maskovania s nulou paketov vám hovorí, že požiadavka nikdy nedorazila na tunelové rozhranie, čo ukazuje späť na trasu LAN alebo na vlastnú smerovaciu tabuľku klienta. Pravidlo s paketmi, ale bez odpovedí, ukazuje na stranu VPC, autorizačné pravidlá alebo skupinu zabezpečenia, ktorá neprijíma preložený zdroj. Čítajte oba smery, kým niečo zmeníte, pretože počet rastúci len na jednej strane je jednosmerná cesta, nie pomalá.

Pamätajte, že koncový bod je spravovaná služba. Neexistuje konfiguračný súbor servera na úpravu ani direktíva client-config na pridanie, takže pokyny napísané pre samostatne spravovaný server OpenVPN s vlastnými trasami klientskych podsietí sa neprenášajú. V AWS sú pákami priradenie podsiete, autorizačné pravidlá a smerovacie tabuľky VPC.

Zdieľaná identita je časť, na ktorú musí politika odpovedať

Každé zariadenie za bránou používa reláciu VPN brány. Autorizačné pravidlá koncového bodu dávajú prístup používateľovi alebo skupine a z pohľadu služby je v tejto relácii presne jeden používateľ. Lokálne preposielanie túto identitu nenásobí do overovania pre jednotlivé zariadenia a nerozširuje kontroly stavu zariadení na tlačiareň v rohu.

To môže byť prijateľné, alebo to môže byť dôvod, prečo je návrh odmietnutý. Závisí to od toho, čo zdroje VPC predpokladajú o tom, kto volá. Zdieľaná identita, ktorá zapadá do autorizačného modelu, je v poriadku; tá, ktorá ticho premení jednu overenú reláciu na prístup do celej LAN, je zistenie čakajúce na napísanie.

Ak je požiadavkou skutočne pripojiť celú lokalitu k VPC, porovnajte podporovaný návrh lokalita-lokalita, kým rozšírite klienta vzdialeného prístupu. Sémantika sa líši a NAT-ovaná klientska relácia je slabou náhradou prepojenia lokality, keď VPC musí iniciovať spojenia do LAN.

Rozhodnite klienta, trasu, preklad a príbeh identity v tomto poradí. Každé obmedzuje ďalšie a poradie vysvetľuje, prečo hostiteľ funguje, zatiaľ čo LAN nie.