Sur kiuj havenoj OpenVPN Access Server fakte aŭskultas?
Trairu la soketan liston sur Access Server-gastiganto: rekonu la defaŭltajn aŭskultantojn, distingi loopback de publikigitaj, kaj kontrolu plusendadon antaŭ ol fermi havenon.
Vi rulas ss -lntup sur Access Server-gastiganto kaj ricevas liston duoble pli longan ol atendite. Duono de la eroj estas demonformaj havenoj, pri kiuj neniu menciis dum la agordo. La reflekso estas fermi ĉion, kio ne estas 443 aŭ 1194, kaj tiel homoj rompas sian propran klientan portalon.
Access Server ne estas unu aŭskultanto. Ĝi estas VPN-servo, reta servo kaj klastera partoprenanto, kaj ĝi povas generi kromajn demon-specifajn havenojn kaj fajroŝirmilajn plusendadojn depende de kiom da TCP-demondoj vi agordis.
Trairu la inventaron laŭ ordo: legu la soketojn, mapu la konatajn, klasifiku la ceterajn laŭ posedanto kaj bindo, kaj poste kontrolu, kio fakte publikigas ilin.
Komencu per unu nurlega komando
sudo ss -lntup donas al vi transporton, lokan adreson, havenon kaj posedantan procezon por ĉiu aŭskultanta soketo. La flagoj gravas: -l aŭskultado, -n nombra, -t TCP, -u UDP, -p procezo. Sen root vi ricevas soketojn sed ne procezajn nomojn, kaj tio estas ĝuste la kolumno, kiun vi bezonas por klasifiko.
Notu kvar kampojn po vico antaŭ ol formi ajnan opinion: protokolo, binda adreso, haveno kaj komando. Tenu la version de Access Server kaj la agorditan nombron de demondoj apud tiu listo, ĉar ambaŭ ŝanĝas tion, kio estas atendata.
Du vicoj, kiuj aspektas identaj, ne estas. TCP kaj UDP sur la sama numero estas apartaj soketoj kun aparta eksponiĝo, kaj 0.0.0.0 kaj :: estas apartaj bindoj por apartaj adresfamilioj. Servo ligita nur al 127.0.0.1 ne estas rekte atingebla de alia gastiganto, kvankam loka plusendado ankoraŭ povas publikigi ĝin.
La aŭskultantoj, kiujn vi devus rekoni
Ĉi tiuj defaŭltoj kovras la plej multajn instaladojn kaj donas al vi bazlinion por kompari. Ili estas defaŭltoj, ne kompleta permeslisto.
| 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 |
Ĉio preter tio bezonas klarigon, ne supozon. Vi ofte vidos nur-lokajn aŭskultantojn apartenantajn al komponantoj, kiujn la produkto instalas por si mem. Konfirmu ilin per PID kaj serva agordo anstataŭ per memorita havena numero, kaj ne traktu nekonatan havenon kiel malamikan nur pro nekonateco.
Soketo ekster la konata paro ankaŭ ne estas aŭtomate restaĵo. Kiam pluraj TCP-demondoj estas agorditaj, Access Server kreas aŭskultantojn po demono kaj plusendas trafikon al ili, do ilia nombro kaj havenaj valoroj sekvas tiun agordon.
Klasifiku antaŭ ol fermi ion
Por ĉiu necerta vico, respondu tri demandojn laŭ ĉi tiu ordo.
- Posedanto kaj celo. Parigu la PID al unuo aŭ procezo kaj legu la agordon de tiu servo. Se vi ne povas nomi la posedanton, vi ne pretas decidi ion pri la soketo.
- Binda amplekso. Loopback estas loka al la nomspaco. Wildcard-bindo estas atingebla nur se enkursigado, gastiganta filtrado kaj iuj ajn nubnivelaj reguloj permesas tion, do la binda adreso estas necesa sed ne sufiĉa. Kontrolu IPv4 kaj IPv6 kiel apartajn decidojn.
- Publikigita vojo. Serĉu servan plusendadon, demon-specifajn plusendadojn, eksteran prokurilon kaj la efektivan fajroŝirmilan politikon. Tio estas la paŝo, kiun homoj preterlasas, kaj ĝi estas tiu, kiu transformas sendanĝere aspektantan backend-havenon en atingeblan administran vojon.
La sama demando legiĝas alie de ekster la gastiganto. Havenon sen gastiganta fajroŝirmila regulo ankoraŭ povas fermi nuba sekureca grupo, kaj haveno kun permesa gastiganta regulo povas esti neatingebla ĉar nenio enkursigas al ĝi. Rigardu ambaŭ finojn antaŭ ol skribi la konkludon de la inventaro.
Kie la publikigita vojo diferencas de la soketa listo
La propra dokumentaro de Access Server kovras la kazon, kiu kaŭzas la plej grandan konfuzon: kiam pluraj TCP-demondoj funkcias, la fronta haveno plusendas al demon-specifaj havenoj, kaj la videbla aranĝo ĉesas kongrui kun la soketa listo. La lernilo pri filtrado de la reta interfaco priskribas tiujn regulojn kaj kial filtrilo skribita nur por la evidenta haveno povas tute maltrafi la plusenditan vojon.
Klastera kontrolo estas la dua loko, kie la versio gravas. En 3.0 kaj pli nova ĝi dividas 943; pli malnovaj klasteraj agordoj uzis 945. Malfermi aŭ bloki unu el ili sen kontroli la version produktas inventaron, kiu aspektas ordema kaj estas malĝusta.
Do la ekstere videbla surfaco estas la unio de tri aferoj: aŭskultantaj soketoj, plusendaj reguloj, kiuj republikigas ilin, kaj la retaj kontroloj antaŭ la gastiganto. Ĉiu inventaro, kiu registras nur la unuan, estas nekompleta, kaj ĉiu ŝanĝo, kiu konsideras nur la unuan, aŭ lasos vojon malfermita aŭ tranĉos servon.
Kontrolu post ĉiu ŝanĝo
Ŝanĝu aŭskultantajn agordojn per la subtenata agorda posedanto kaj tenu reakiran konsolon malfermita dum vi tion faras. Perdi administran aliron al reta interfaco sur fora gastiganto ne estas reakirebla per la VPN, kiun vi ĵus malŝaltis.
Poste validigu la kvar aferojn, kiujn instalado kutime bezonas: VPN-kliento konektiĝas, la klienta portalo ŝarĝiĝas, administra aliro funkcias, kaj klastera komunikado ankoraŭ funkcias, se vi rulas pli ol unu nodon. Testo nur pri VPN pasas komforte dum la portalo estas rompita.
Finu skribante la permesitan vojon por ĉiu servo: kiu soketo, kiu bindo, kiu plusenda regulo, kiu reta kontrolo. Tiu dokumento estas la utila sekureca produktaĵo. Minimuma soketa nombro ne estas, kaj nek estas amasa restarigo, kiu fermas aŭskultantojn, kiujn neniu finis identigi.