Mantendu SSH lokala ostalari irteera VPN bat erabiltzen duenean

Linux zerbitzari txiki batek irteerako VPN bat exekutatzen du ostatatzen duen aplikaziorako, eta administratzaileak oraindik SSH bidez heldu nahi dio alboko mahaitik. Baldintza zentzuzkoa da, eta normalean ez du portu birbideratzerik, hornitzailearen helbiderik ezta tunelaren zulorik behar. Behar duena helburu jakin batekin diseinatutako kudeaketa-bide bat da, VPN bezeroak bideratze-taularekin egin zuenetik heredatua izan beharrean.

Ondorengo urratsetan administratzailea LAN berean dagoela suposatzen da.Urrutiko administrazioa beste erantzun bat duen beste arazo bat da.

Lotu SSH administratzaileek erabiltzen duten helbidera

Hasi entzulearekin.ss -ltnp | grep :22 erakusten du zeri lotuta dagoen sshd, eta 0.0.0.0 helbideko entzule batek interfaze guztietatik onartzen ditu konexioak, tunela barne. LANaren helbidera lotzea estuagoa da eta asmoa ikusgai egiten du:ListenAddress 192.168.10.20 barruan sshd_config, ondoren konfigurazio-proba bat eta birkarga bat. Helbide horretako tipografia-akats bat komodin bat baino ikusgaiagoa da, sshd-k abiatzeari uko egiten diolako helbidea existitzen ez denean.

Mantendu ostalari-gakoaren egiaztapena eta erabiltzaile bakoitzeko autentifikazioa dauden bezala. «Sare lokala besterik ez da» ez da autentifikazio-metodo bat, eta bidea laburra delako gakoaren egiaztapena saltatzen duen kudeaketa-kanal bat abusatzeko zain dagoen kudeaketa-kanal bat da. DHCP erreserba batek edo helbide estatiko batek helburua aurreikusteko modukoa egiten du, zerbitzariaren identitate publikoa bihurtu gabe.

Mantendu LANaren ibilbidea tunelaz kanpo

192.168.10.0/24 helbidea duen ostalari batek aurrizki horretarako konektatutako ibilbidea du, eta ibilbide zehatzago batek VPNaren lehenespena gainditzen du taula berean. Horregatik tokiko SSHak sarritan bere kabuz funtzionatzen jarraitzen du tunela igotzean. Egiaztatu hori suposatu beharrean:ip route get 192.168.10.50 kernelak erabiliko lukeen interfazea eta iturburu-helbidea izendatzen ditu, eta erantzunak LANeko gailua izan beharko luke, ez tunela. Errepikatu egiaztapena administratzailearen makinatik ere, haren taulak erabakitzen baitu paketeak iristen diren ala ez. Kable bereko bi ostalarik bat etorri ez daitezke norabide zein den irisgarri.

Suposizioa bi lekutan hausten da. Politikan oinarritutako bideratze-arau batek trafikoa taula batera bidal dezake, zeinaren lehenespena tunelera seinalatzen duen taula nagusia kontsultatu aurretik. Blokeo edo kill-switch funtzioa duen VPN bezero batek tunelera sartzen ez den trafikoa ere blokea dezake, bideratze-taulak esaten duena edozein dela ere.

Bideratutako kudeaketa-VLANak dira beste kasua. Administratzailea 192.168.50.0/24-n badago router lokalaren atzean, zerbitzariak aurrizki horretarako ibilbide esplizitua behar du 192.168.10.1 bidez, eta ibilbide horrek berriz konektatzea gainditu behar du. Mantendu salbuespena kudeaketa-aurrizkirako zehatza; barruti pribatuetarako salbuespen zabal batek tunelaren helburua deuseztatzen du.

Egin suebakiaren salbuespena araua bezain estua

Ostalariak suebaki bat badu, baimendu SSH kudeaketa-iturburutik soilik eta LANeko interfazean soilik. 22 portua edonondik onartzen duen araua baldintza baino zabalagoa da eta berrikuspenean justifikatzeko zailagoa. nftables ostalari batean araua sarrera-katean dagokio, interfazea eta iturburua bat etorriz; iptables ostalari batean baliokidea -i eta -s gaineko bi bat-etortzeen pare bat da. Komentatu araua zerbitzatzen duen administratzaile-taldearekin, hurrengo auditoriak ez dezan asmatu behar 22 portua zergatik dagoen irekita.

Egiaztatu VPN bezeroaren berezko iragazkia ere. Zenbait bezerok tokiko trafikoa diseinuz baztertzen duten arauak instalatzen dituzte, eta bezero-mailako bazterketa baten gaineko suebaki-arau zuzen batek ez du ezer aldatzen. Irakurri bezeroaren konfigurazioa ostalariaren suebakia editatu aurretik, bi iragazkik seriean bietako ezein ez bezalako hutsegitea sortzen baitute.

Probatu bi egoerak

Exekutatu proba bi aldiz: behin tunela konektatuta eta behin deskonektatuta. Egoera bakoitzean, berretsi entzulea, ibilbidea eta SSH saio-hasiera erreala administratzailearen makinatik. Tunela igota dagoen bitartean soilik funtzionatzen duen bidea ez da tokiko kudeaketa-bide bat; kasualitatea da.

Ondoren berrabiarazi tunela SSH saio bat irekita dagoen bitartean. Bizirik irauten duen saio batek bideratzea egonkorra dela frogatzen du; erortzen den saio batek bezeroak berriz konektatzean ibilbideak edo iragazkiak berridazten dituela esaten dizu, eta hori gertakari baten aurretik jakitea merezi du, ez bitartean.

Idatzi probatu zenuen iturburu-helbidea, 192.168.10.50rako idatzitako arau batek isilik huts egiten baitu administratzailearen eramangarria beste azpisare batera mugitzen denean.

Idatzi berreskuratze-bidea runbookean

Erabaki orain zer gertatzen den irteerako VPNak tokiko bidea apurtzen badu. Kontsolako sarbidea, bigarren kudeaketa-helbide bat edo bezeroa gelditzeko dokumentatutako prozedura bat erantzun legitimoak dira denak, eta horietako edozein hobea da problema saioa hasi behar duzun unean aurkitzea baino. Zerbitzaria urrun badago, tokiko bidea ez da existitzen, eta diseinu zuzena onartutako urrutiko sarbide-ibilbide bereizi bat edo bastioi bat da, ez portu publiko agerian utzi bat.

Mantendu bi rolak bereizita dokumentazioan: tokiko SSH gertu dagoen administratzailearentzat, eta irteerako tunela aplikazioaren trafikoarentzat. Rola horiek idatzita daudenean, edozeinetan etorkizuneko aldaketak egiaztatzeko leku nabarmena du, eta hurrengo pertsonak ez du berriro aurkitu behar VPN bat duen zerbitzari batek zergatik erantzuten jarraitzen duen bere LAN helbidean.