Op hokker poarten harket OpenVPN Access Server eins?
Rin troch de socketlist op in Access Server-host: werken de standert-harkers, ûnderskied loopback fan publisearre en kontrolearje trochstjoering foar’t jo in poarte slute.
Jo rinne ss -lntup op in Access Server-host en krije in list twa kear sa lang as ferwachte. De helte fan de ynfieringen binne daemonfoarmige poarten dy’t nimmen by de opset neamde. De refleks is alles te sluten dat gjin 443 of 1194 is, en sa brekke minsken har eigen kliïntportal.
Access Server is net ien harker. It is in VPN-tsjinst, in webtsjinst en in klusterdielnimmer, en it kin ekstra daemonspesifike poarten en firewall-trochstjoeringen oanmeitsje, ôfhinklik fan hoefolle TCP-daemons jo konfigurearre hawwe.
Rin de ynventarisaasje yn oarder troch: lês de sockets, map de bekende, klassifisearje de rest op eigner en binding, en kontrolearje dan wat se eins publisearret.
Begjin mei ien allinnich-lêzen-opdracht
sudo ss -lntup jout jo transport, lokale adres, poarte en eignerproses foar elke harkende socket. De flaggen binne wichtich: -l harkje, -n nûmerich, -t TCP, -u UDP, -p proses. Sûnder root krije jo sockets mar gjin prosesnammen, en dat is krekt de kolom dy’t jo foar klassifikaasje nedich hawwe.
Skriuw fjouwer fjilden per rige op foar’t jo in miening foarmje: protokol, bindadres, poarte en opdracht. Hâld de Access Server-ferzje en it konfigurearre oantal daemons neist dy list, want beide feroarje wat ferwachte wurdt.
Twa rigen dy’t identyk lykje binne net. TCP en UDP op itselde nûmer binne aparte sockets mei aparte bleatstelling, en 0.0.0.0 en :: binne aparte bindings foar aparte adresfamyljes. In tsjinst dy’t allinnich oan 127.0.0.1 bûn is, is net direkt berikber fan in oare host, hoewol in lokale trochstjoering it noch altyd publisearje kin.
De harkers dy’t jo werkenne moatte
Dizze standertwearden dekke de measte ynstallaasjes en jouwe jo in basisline om mei te fergelykjen. It binne standertwearden, gjin folsleine talittingslist.
| 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 |
Alles dêrfoarby freget in útliz, gjin oanname. Jo sille faak allinnich-lokale harkers sjen dy’t ta komponinten hearre dy’t it produkt foar himsels ynstallearret. Befêstigje se fia PID en tsjinstkonfiguraasje ynstee fan in ûntholden poartenûmer, en behannelje in ûnbekende poarte net as fijannich allinnich om’t er ûnbekend is.
In socket bûten it bekende pear is ek net automatysk in oerbliuwsel. As meardere TCP-daemons konfigurearre binne, makket Access Server harkers per daemon en stjoert ferkear dêrhinne, sadat har oantal en poartewearden dy konfiguraasje folgje.
Klassifisearje foar’t jo wat slute
Beäntwurdzje foar elke ûnwis rige trije fragen yn dizze oarder.
- Eigner en doel. Keppelje de PID oan in ienheid of proses en lês de konfiguraasje fan dy tsjinst. As jo de eigner net beneame kinne, binne jo net klear om wat oer de socket te besluten.
- Bindingsomfang. Loopback is lokaal foar de nammeromte. In wildcard-binding is allinnich berikber as routing, hostfiltering en eventuele regels op wolknivo it tastean, dus it bindadres is needsaaklik mar net genôch. Kontrolearje IPv4 en IPv6 as aparte besluten.
- Publisearre paad. Sykje nei tsjinsttrochstjoering, daemonspesifike trochstjoeringen, in eksterne proxy en it effektive firewallbelied. Dit is de stap dy’t minsken oerslane, en it is dyselde dy’t in ûnskealik lykjende backend-poarte yn in berikber administratyf paad feroaret.
Deselde fraach lêst oars fan bûten de host. In poarte sûnder host-firewallregel kin noch altyd troch in wolkbefeiligingsgroep sletten wurde, en in poarte mei in talittende hostregel kin ûnberikber wêze om’t neat dêrhinne rûtelet. Sjoch nei beide einen foar’t jo de konklúzje fan de ynventarisaasje skriuwe.
Wêr’t it publisearre paad fan ’e socketlist ferskilt
Access Server syn eigen dokumintaasje behannelet it gefal dat de measte betizing feroarsaket: as meardere TCP-daemons rinne, stjoert de frontpoarte troch nei daemonspesifike poarten, en de sichtbere opbou hâldt op mei it passen by de socketlist. De tutorial oer it filterjen fan ’e webynterface beskriuwt dy regels en wêrom’t in filter dat allinnich foar de foar de hân lizzende poarte skreaun is, it trochstjoerde paad folslein misse kin.
Klusterbehear is it twadde plak wêr’t de ferzje fan belang is. Op 3.0 en nijer dielt it 943; âldere klusterkonfiguraasjes brûkten 945. Ien fan beide iepenje of blokkearje sûnder de ferzje te kontrolearjen jout in ynventarisaasje dy’t der kreas útsjocht en ferkeard is.
Sa is it fan bûten sichtbere oerflak de feriening fan trije dingen: harkende sockets, trochstjoeringsregels dy’t se opnij publisearje, en de netwurkbestjoerings foar de host. Eltse ynventarisaasje dy’t allinnich it earste fêstleit is ûnfolslein, en eltse feroaring dy’t allinnich it earste beskôget sil of in paad iepen litte of in tsjinst ôfsnije.
Ferifiearje nei elke feroaring
Feroarje harker-ynstellingen fia de stipe konfiguraasje-eigner en hâld in werstelkonsole iepen wylst jo dat dogge. Ferlies fan administratyf tagong ta in webynterface op in fiere host is net werom te heljen fia de VPN dy’t jo krekt útskeakele hawwe.
Falidearje dan de fjouwer dingen dy’t in ynstallaasje normaal nedich hat: in VPN-kliïnt ferbynt, it kliïntportal laden, administratyf tagong wurket, en klusterkommunikaasje funksjonearret noch as jo mear as ien knooppunt draaie. In test allinnich foar VPN slagget noflik wylst it portal stikken is.
Einigje troch it tastiene paad foar elke tsjinst op te skriuwen: hokker socket, hokker binding, hokker trochstjoeringsregel, hokker netwurkbestjoering. Dat dokumint is de nuttige befeiligingsútkomst. In minimaal socketoantal is dat net, en in massale reset dy’t harkers slút dy’t nimmen klear krigen hat te identifisearjen ek net.