Zein portutan entzuten du benetan OpenVPN Access Server-ek?

Exekutatzen duzu ss -lntup Access Server ostalari batean eta espero zena baino bi aldiz luzeagoa den zerrenda lortzen duzu. Sarreren erdiak inork instalazioan aipatu ez zituen daemon formako portuak dira. Erreflexua 443 edo 1194 ez den guztia ixtea da, eta horrela jendeak bere bezero ataria apurtzen du.

Access Server ez da entzule bakarra. VPN zerbitzua, web zerbitzua eta klusterreko partaidea da, eta konfiguratutako TCP daemon kopuruaren arabera daemonen berariazko portu gehigarriak eta firewall birbideratzeak sor ditzake.

Egin inbentarioa ordenan: irakurri socketak, mapatu ezagunak, sailkatu gainerakoak jabearen eta loturaren arabera, eta gero egiaztatu zer den benetan haiek argitaratzen dituena.

Hasi irakurketa hutseko komando batekin

sudo ss -lntup garraioa, tokiko helbidea, portua eta jabe den prozesua ematen ditu entzuten duen socket bakoitzeko. Banderak garrantzitsuak dira: -l entzutea, -n zenbakizkoa, -t TCP, -u UDP, -p prozesua. Root gabe socketak lortzen dituzu baina ez prozesuen izenak, eta horixe da sailkatzeko behar duzun zutabea.

Idatzi lau eremu errenkada bakoitzeko iritzirik osatu aurretik: protokoloa, lotura helbidea, portua eta komandoa. Eutsi Access Server bertsioa eta konfiguratutako daemon kopurua zerrenda horren ondoan, biak aldatzen baitute espero dena.

Beraz, berdinak diruditen bi errenkada ez dira berdinak. Zenbaki berean TCP eta UDP esposizio bereiziko socket bereiziak dira, eta 0.0.0.0 eta :: helbide familia bereizietarako lotura bereiziak dira. 127.0.0.1 helbidera soilik lotuta dagoen zerbitzua ez da zuzenean iristen beste ostalari batetik, tokiko birbideratze batek oraindik argitara dezakeen arren.

Ezagutu beharko zenituzkeen entzuleak

Lehenetsitako balio hauek inplementazio gehienak estaltzen dituzte eta alderatzeko oinarria ematen dizute. Lehenetsitakoak dira, ez baimenduen zerrenda osoa.

Hortik haragoko ezerk azalpena behar du, ez suposizioa. Askotan produktuak beretzat instalatzen dituen osagaien tokiko entzuleak soilik ikusiko dituzu. Egiaztatu horiek PIDaren eta zerbitzuaren konfigurazioaren bidez, gogoratutako portu zenbaki baten ordez, eta ez tratatu portu ezezaguna etsaitzat ezezaguna delako bakarrik.

Par ezagunaz kanpoko socket bat ere ez da automatikoki hondarra. TCP daemon batzuk konfiguratuta daudenean, Access Server-ek daemon bakoitzeko entzuleak sortzen ditu eta trafikoa haietara birbideratzen du, beraz haien kopuruak eta portu balioek konfigurazio hori jarraitzen dute.

Sailkatu zerbait itxi aurretik

Errenkada zalantzagarri bakoitzeko, erantzun hiru galderari ordena honetan.

1. Jabea eta helburua. Lotu PIDa unitate edo prozesu batekin eta irakurri zerbitzu horren konfigurazioa. Jabea izendatu ezin baduzu, ez zaude socketari buruz ezer erabakitzeko prest.
2. Loturaren irismena. Loopback izen-espazioarekiko tokikoa da. Wildcard lotura soilik da irisgarria bideratzeak, ostalariaren iragazketak eta hodei mailako edozein arauk baimentzen badute, beraz lotura helbidea beharrezkoa da baina ez nahikoa. Egiaztatu IPv4 eta IPv6 erabaki bereizi gisa.
3. Argitaratutako bidea. Bilatu zerbitzu birbidalketa, daemonen berariazko birbideratzeak, kanpoko proxy bat eta firewall politika eraginkorra. Hau da jendeak saltatzen duen urratsa, eta itxuraz kaltegabea den backend portu bat administrazio bide irisgarri bihurtzen duena.

Galdera berak beste modu batera irakurtzen da ostalariaren kanpotik. Ostalariaren firewall araurik gabeko portu bat hodeiko segurtasun talde batek itxi dezake oraindik, eta ostalari arau baimengarridun portu bat iristezina izan daiteke ezer hara bideratzen ez delako. Begiratu bi muturrak inbentarioaren ondorioa idatzi aurretik.

Argitaratutako bidea socket zerrendatik desberdintzen den tokia

Access Server-en dokumentazioak berak nahasmen handiena sortzen duen kasua estaltzen du: TCP daemon batzuk exekutatzen direnean, aurreko portuak daemonen berariazko portuetara birbidaltzen du, eta ikusgai den antolamenduak socket zerrendarekin bat egiteari uzten dio. web interfazearen iragazketari buruzko tutoriala arau horiek deskribatzen ditu eta zergatik portu nabarirako soilik idatzitako iragazki batek birbideratutako bidea erabat gal dezakeen.

Kluster kontrolak bertsioak garrantzia duen bigarren tokia da. 3.0 eta berriagoetan 943 partekatzen du; kluster konfigurazio zaharrek 945 erabiltzen zuten. Horietako bat bertsioa egiaztatu gabe irekitzeak edo blokeatzeak itxura oneko eta okerra den inbentarioa sortzen du.

Beraz, kanpotik ikusgai den azalera hiru gauzaren batasuna da: entzuten duten socketak, haiek berriro argitaratzen dituzten birbidalketa arauak eta ostalariaren aurreko sare kontrolak. Lehenengoa soilik erregistratzen duen inbentarioa osatugabea da, eta lehenengoa soilik aztertzen duen edozein aldaketak bidea irekita utziko du edo zerbitzu bat moztuko du.

Egiaztatu edozein aldaketaren ondoren

Aldatu entzule ezarpenak onartutako konfigurazio jabearen bidez eta eduki berreskuratze kontsol bat irekita hori egiten duzun bitartean. Urrutiko ostalari bateko web interfazearen administrazio sarbidea galtzea ez da berreskuragarria oraintxe desgaitu duzun VPNaren bidez.

Gero baliozkotu inplementazio batek normalean behar dituen lau gauzak: VPN bezero bat konektatzen da, bezero ataria kargatzen da, administrazio sarbideak funtzionatzen du, eta kluster komunikazioak funtzionatzen jarraitzen du nodo bat baino gehiago exekutatzen badituzu. VPN soilik proba erosotasunez pasatzen da ataria hondatuta dagoen bitartean.

Amaitu zerbitzu bakoitzeko baimendutako bidea idatziz: zein socket, zein lotura, zein birbidalketa arau, zein sare kontrol. Dokumentu hori da segurtasun emaitza erabilgarria. Socket kopuru minimoa ez da, eta ezta inork identifikatzen amaitu ez dituen entzuleak ixten dituen berrezarpen masiboa ere.