Kodėl „Access Server“ klientai nepasiekiami iš LAN

Nešiojamasis kompiuteris prisijungia, tunelis pakeltas, o užklausos į vidinę paslaugą pakimba jungiantis. Pačioje paslaugoje užklausa ateina iš adreso, panašaus į 10.90.0.25, atsakymas išeina numatytojo šliuzo link, ir niekas negrįžta, nes tas šliuzas neturi supratimo, kur yra 10.90.0.25. Iš kitos pusės ta pati klaida atrodo kaip vidinis mazgas, kuris negali pinginti prisijungusio kliento. Abi yra vienas trūkstamas objektas: grįžimo maršrutas į VPN klientų baseiną, kurį gali pridėti tik privatus tinklas.

Perskaitykite šaltinio adresą, kurį mato paslauga

Tas vienas laukas nulemia viską. Jei vidinė paslauga mato baseino adresą, Access Server maršrutizuoja, o ne slepia kliento srautą, ir kiekvienas atsakymas turi būti maršrutizuojamas atgal į baseiną. Jei vietoj to ji mato paties serverio privatų adresą, serveris maskuoja ir grįžimo kelias jau veikia, bet už tai prarandama bet kokia atskiro kliento tapatybė paslaugos žurnaluose ir prieigos taisyklėse.

Prieš ką nors keisdami palyginkite abu galus. Serveryje išvardykite tunelio sąsajas ir jų adresus; kliente patvirtinkite, kurį iš tų adresų jis iš tikrųjų turi; vidiniame mazge pažiūrėkite į aktyvų ryšį.

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

Paskutinė komanda yra ta, kuri sugenda lūžusioje situacijoje: ji arba praneša tunelio prefiksą kaip nepasiekiamą, arba, dar blogiau, grąžina jūsų numatytąjį šliuzą, ir taip atsakymai atsiduria internete.

Nelaikykite, kad baseinas tik vienas. Serveris gali turėti dinaminį intervalą ir kiekvieno naudotojo statinius priskyrimus, o statinis adresas gali būti visiškai už dinaminio prefikso ribų. Jei maršrutizuosite tik tą intervalą, kurį atsimenate, naudotojai su fiksuotais adresais liks sulaužyti, o visi kiti praneš, kad problema išspręsta.

Pridėkite maršrutą ten, kur sprendžiamas atsakymas

Maršrutas priklauso šliuzui, kurį vidinė paslauga jau naudoja, o ne paslaugai, nebent ji pati maršrutizuoja savo srautą. Nukreipkite jį į pasiekiamą privatų Access Server adresą, kuris skiriasi nuo kliento turimo tunelio adreso.

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

Debesų tinkle tas pats teiginys tampa maršrutų lentelės įrašu, kurio tikslas yra egzempliorius arba tinklo sąsaja, kurioje veikia serveris, o toje sąsajoje išjungta šaltinio ir paskirties patikra. Atkreipkite dėmesį, ko tas įrašas nedaro: maršrutas nėra prieigos suteikimas, todėl saugos grupės, tinklo ACL ir mazgo užkarda vis tiek turi leisti srautą.

Padarykite jį nuolatinį ir laikykite baseinų dydžius sąžiningais. Du negretimi baseinai reikalauja dviejų maršrutų, o baseinas, išaugęs už sukonfigūruoto prefikso, tyliai sukuria klientus, kurių atsakymai neturi kur dėtis. Jei valdote baseinų intervalus, pasirinkite suvestinę, kurią galite maršrutizuoti vieną kartą ir palikti.

Persiuntimas ir filtrai turi sutikti su maršrutu

Maršrutizavimas yra tik pusė kelio. Serveriui turi būti leista persiųsti tarp tunelio ir privačios sąsajos, o Linux tai reiškia net.ipv4.ip_forward ir persiuntimo grandinę, leidžiančią sąsajų porą, o sukietintame mazge paprastai atskirą aiškią taisyklę kiekvienai krypčiai.

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

Būsenos filtravimas paaiškina simptomą, kuris nukreipia žmones neteisingu keliu. Atsakymui nusistovėjusiame sraute nereikia naujos įeinančios taisyklės, todėl ryšys, pakimbantis po SYN-ACK, nėra blokuojamas trūkstamos priėmimo taisyklės; jis numetamas arba neteisingai maršrutizuojamas. Išsaugokite šį skirtumą, nes jis atskiria maršrutizavimo pakeitimą nuo užkardos pakeitimo.

Asimetriški grįžimo keliai yra tylesnė tos pačios problemos versija. Jei baseiną pasiekia du maršrutai ir atsakymas pasirenka tą, kuris išeina per kitą sąsają nei ta, kuria atėjo užklausa, griežtas atvirkštinio kelio filtravimas jį numeta, ir srautas žlunga tik kai kuriems klientams.

Maršrutizuotas ar maskuojamas: rinkitės sąmoningai

Maršrutizuotas režimas išsaugo kliento baseino adresą paslaugoje, todėl įmanomas kiekvieno kliento registravimas ir politika, o mainais kiekvienas vidinis tinklas, kuris turi atsakyti klientui, turi turėti baseino maršrutą. Maskuojamas režimas panaikina šį reikalavimą, nes atsakymai grįžta į serverį, tačiau paslauga nebegali atskirti vieno kliento nuo kito ir negali nieko inicijuoti konkretaus kliento link.

Šio elgesio keitimas veikiančiame serveryje nutraukia esamas sesijas, todėl pirmiausia išbandykite su vienu klientu ir vienu srautu. Jei perjungimas yra teisingas atsakymas, tai konfigūracijos sprendimas serveryje, o ne kažkas, ką apeinama pridedant maršrutus, kurie vėliau taps nereikalingi.

Potinklis už kliento yra atskira užduotis

Prieiga prie įrenginio pačiame nešiojamojo kompiuterio LAN nėra tas pats, kas pasiekti nešiojamojo kompiuterio tunelio adresą. Tam reikia, kad klientas veiktų kaip potinklio šliuzas: deklaruotas kliento pusės tinklas, įjungtas persiuntimas kliento operacinėje sistemoje ir maršrutas tame LAN atgal į klientą. Privataus tinklo maršruto pridėjimas nešiojamojo kompiuterio namų intervalui to nepadaro ir sukuria konfliktus, kai du naudotojai turi tą patį namų intervalą.

Kryptis taip pat yra politikos klausimas. Leidimas klientui atidaryti ryšį į vidinę paslaugą automatiškai neleidžia vidiniam mazgui atidaryti ryšio į tą klientą. Prieš darydami išvadą, kad kelias sulaužytas, patikrinkite serverio prieigos politiką ir kliento mazgo užkardą.

Patikrinkite vienu srautu ir vienu įrašu

Įrodykite kelią vienu ryšiu, o ne bendru pasiekiamumo testu. Stebėkite tą patį srautą abiejuose galuose: užklausą, ateinančią į paslaugą, ir atsakymą, ją paliekantį.

tcpdump -ni any host 10.90.0.25 and port 443

Prieš pataisymą įrašas rodo atsakymą išeinantį link šliuzo, kuris jo nemaršrutizuos. Po pataisymo atsakymas išeina link serverio ir srautas pasibaigia. Tada patvirtinkite maršrutą, kurį šliuzas naudotų antrajam kliento adresui, kad nepadengtas baseinas pasimatytų dabar, o ne po savaitės.

Užbaikite keturiomis patikromis, kurios tai uždaro: šaltinio adresas paslaugoje atitinka numatytą režimą, šliuzas turi maršrutą į kiekvieną naudojamą baseiną, persiuntimas ir filtrai leidžia abi kryptis, ir vienas tikras srautas praeina nuo pradžios iki pabaigos. „Access Server“ maršrutizavimo DUK nurodo tą patį principą įdiegtai versijai, kurios palaikoma konfigūracijos sąsaja gali skirtis nuo senesnių vadovų.