Kuriuose portuose iš tikrųjų klausosi OpenVPN Access Server?
Peržiūrėkite Access Server hosto lizdų sąrašą: atpažinkite numatytuosius klausytojus, atskirkite loopback nuo paskelbtų ir prieš uždarydami portą patikrinkite persiuntimą.
Jūs vykdote ss -lntup Access Server hoste ir gaunate dvigubai ilgesnį sąrašą nei tikėtasi. Pusė įrašų yra demono formos portai, kurių niekas nepaminėjo montavimo metu. Refleksas yra uždaryti viską, kas nėra 443 arba 1194, ir taip žmonės sugadina savo klientų portalą.
Access Server nėra vienas klausytojas. Tai VPN paslauga, žiniatinklio paslauga ir klasterio dalyvis, ir jis gali generuoti papildomus demonams būdingus portus bei užkardos peradresavimus priklausomai nuo to, kiek TCP demonų sukonfigūravote.
Peržiūrėkite sąrašą iš eilės: perskaitykite lizdus, susiekite pažįstamus, klasifikuokite likusius pagal savininką ir susiejimą, tada patikrinkite, kas juos iš tikrųjų skelbia.
Pradėkite nuo vienos tik skaitymo komandos
sudo ss -lntup pateikia transportą, vietinį adresą, portą ir savininko procesą kiekvienam klausančiam lizdui. Vėliavėlės svarbios: -l klausymasis, -n skaitinis, -t TCP, -u UDP, -p procesas. Be root gausite lizdus, bet ne procesų pavadinimus, o klasifikavimui reikia būtent to stulpelio.
Prieš formuodami nuomonę kiekvienai eilutei užrašykite keturis laukus: protokolas, susiejimo adresas, portas ir komanda. Laikykite Access Server versiją ir sukonfigūruotą demonų skaičių prie to sąrašo, nes abu keičia tai, ko tikimasi.
Dvi vienodai atrodančios eilutės nėra vienodos. TCP ir UDP tuo pačiu numeriu yra atskiri lizdai su atskiru poveikiu, o 0.0.0.0 ir :: yra atskiri susiejimai atskiroms adresų šeimoms. Paslauga, susieta tik su 127.0.0.1 , nėra tiesiogiai pasiekiama iš kito hosto, nors vietinis peradresavimas vis tiek gali ją paskelbti.
Klausytojai, kuriuos turėtumėte atpažinti
Šios numatytosios reikšmės apima daugumą diegimų ir suteikia palyginimo pagrindą. Tai numatytosios reikšmės, o ne visas leidžiamų sąrašas.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Viskas, kas už to, reikalauja paaiškinimo, o ne prielaidos. Dažnai matysite tik vietinius klausytojus, priklausančius komponentams, kuriuos produktas įdiegia sau. Patvirtinkite juos PID ir paslaugos konfigūracija, o ne įsimintu porto numeriu, ir nelaikykite nepažįstamo porto priešu vien dėl to, kad jis nepažįstamas.
Lizdas už pažįstamos poros ribų taip pat nėra automatiškai likutis. Kai sukonfigūruoti keli TCP demonai, Access Server sukuria klausytojus kiekvienam demonui ir nukreipia į juos srautą, todėl jų skaičius ir portų reikšmės atitinka tą konfigūraciją.
Klasifikuokite prieš ką nors uždarydami
Kiekvienai neaiškiai eilutei atsakykite į tris klausimus šia tvarka.
- Savininkas ir paskirtis. Susiekite PID su vienetu ar procesu ir perskaitykite tos paslaugos konfigūraciją. Jei negalite įvardyti savininko, nesate pasirengę nieko spręsti apie lizdą.
- Susiejimo apimtis. Loopback yra vietinis vardų erdvei. Pakaitos simbolio susiejimas pasiekiamas tik jei maršruto parinkimas, hosto filtravimas ir bet kokios debesies lygio taisyklės tai leidžia, tad susiejimo adresas būtinas, bet nepakankamas. Tikrinkite IPv4 ir IPv6 kaip atskirus sprendimus.
- Paskelbtas kelias. Ieškokite paslaugos persiuntimo, demonams būdingų peradresavimų, išorinio tarpinio serverio ir veiksmingos užkardos politikos. Tai žingsnis, kurį žmonės praleidžia, ir būtent jis nekenksmingai atrodantį backend portą paverčia pasiekiamu administraciniu keliu.
Tas pats klausimas skaitomas kitaip iš hosto išorės. Portas be hosto užkardos taisyklės vis tiek gali būti uždarytas debesies saugos grupės, o portas su leidžiančia hosto taisykle gali būti nepasiekiamas, nes niekas į jį nemaršrutizuoja. Pažiūrėkite į abu galus prieš rašydami sąrašo išvadą.
Kur paskelbtas kelias skiriasi nuo lizdų sąrašo
Pačios Access Server dokumentacija aprašo atvejį, kuris sukelia daugiausiai painiavos: kai veikia keli TCP demonai, priekinis portas persiunčia į demonams būdingus portus, ir matomas išdėstymas nustoja atitikti lizdų sąrašą. žiniatinklio sąsajos filtravimo mokymo programa aprašo tas taisykles ir kodėl filtras, parašytas tik akivaizdžiam portui, gali visiškai praleisti peradresuotą kelią.
Klasterio valdymas yra antra vieta, kur versija svarbi. Nuo 3.0 ji dalijasi 943; senesnės klasterio konfigūracijos naudojo 945. Atidaryti ar užblokuoti vieną iš jų nepatikrinus versijos sukuria tvarkingai atrodantį ir neteisingą sąrašą.
Taigi iš išorės matomas paviršius yra trijų dalykų sąjunga: klausantys lizdai, juos iš naujo skelbiančios persiuntimo taisyklės ir tinklo valdikliai prieš hostą. Bet koks sąrašas, kuriame užrašomas tik pirmasis, yra neišsamus, o bet koks pakeitimas, kuriame atsižvelgiama tik į pirmąjį, arba paliks kelią atvirą, arba nutrauks paslaugą.
Patikrinkite po bet kokio pakeitimo
Keiskite klausytojo nustatymus per palaikomą konfigūracijos savininką ir atlikdami tai laikykite atidarytą atkūrimo konsolę. Prarasti administracinę prieigą prie žiniatinklio sąsajos nuotoliniame hoste negalima atkurti per VPN, kurį ką tik išjungėte.
Tada patikrinkite keturis dalykus, kurių diegimui paprastai reikia: VPN klientas prisijungia, klientų portalas įkeliamas, administracinė prieiga veikia ir klasterio ryšys tebeveikia, jei paleidžiate daugiau nei vieną mazgą. Tik VPN testas praeina patogiai, kol portalas sugadintas.
Pabaikite užrašydami leidžiamą kelią kiekvienai paslaugai: kuris lizdas, kuris susiejimas, kuri persiuntimo taisyklė, kuris tinklo valdiklis. Tas dokumentas yra naudingas saugos rezultatas. Minimalus lizdų skaičius nėra, ir masinis atstatymas, kuris uždaro klausytojus, kurių niekas nespėjo identifikuoti, taip pat nėra.