Mbajeni SSH lokal kur hosti përdor një VPN dalëse

Një server i vogël Linux përdor një VPN dalëse për aplikacionin që strehon, dhe administratori ende dëshiron ta arrijë përmes SSH nga tavolina pranë. Është një kërkesë e arsyeshme, dhe zakonisht nuk kërkon as përcjellje portash, as adresë të ofruesit, as ndonjë vrimë në tunel. Ajo që i duhet është një rrugë administrimi e projektuar me qëllim, në vend të trashëguar nga ajo që bëri klienti VPN me tabelën e rrugëzimit.

Hapat më poshtë supozojnë se administratori është në të njëjtin LAN.Administrimi në distancë është problem tjetër me përgjigje tjetër.

Lidhni SSH me adresën që përdorin administratorët

Filloni nga dëgjuesi.ss -ltnp | grep :22 tregon se ku është i lidhur sshd, dhe një dëgjues në 0.0.0.0 pranon lidhje nga çdo ndërfaqe, përfshirë tunelin. Lidhja me adresën e LAN-it është më e ngushtë dhe e bën qëllimin të dukshëm:ListenAddress 192.168.10.20 në sshd_config, e ndjekur nga një test konfigurimi dhe një ringarkim. Një gabim shtypi në atë adresë është më i dukshëm se një karakter i përgjithshëm, sepse sshd refuzon të nisë kur adresa nuk ekziston.

Mbajini kontrollin e çelësit të hostit dhe vërtetimin për çdo përdorues saktësisht ashtu si janë. „Është vetëm rrjeti lokal“ nuk është metodë vërtetimi, dhe një kanal administrimi që kalon verifikimin e çelësit sepse rruga është e shkurtër është një kanal administrimi që pret abuzim. Një rezervim DHCP ose një adresë statike e bën objektivin të parashikueshëm pa e kthyer atë në identitetin publik të serverit.

Mbajeni rrugën e LAN-it jashtë tunelit

Një host me adresë në 192.168.10.0/24 ka një rrugë të lidhur për atë parashtesë, dhe një rrugë më specifike mund të paracaktuarën e VPN-së brenda të njëjtës tabelë. Prandaj SSH lokal shpesh vazhdon të punojë vetë kur tuneli ngrihet. Verifikojeni në vend që ta supozoni:ip route get 192.168.10.50 emërton ndërfaqen dhe adresën e burimit që do të përdorte kerneli, dhe përgjigjja duhet të jetë pajisja e LAN-it, jo tuneli. Përsëriteni kontrollin edhe nga makina e administratorit, sepse tabela e saj vendos nëse paketat arrijnë fare. Dy hoste në të njëjtin kabllo mund të mos bien dakord se cili drejtim është i arritshëm.

Supozimi thyhet në dy vende. Një rregull rrugëzimi i bazuar në politikë mund të dërgojë trafikun në një tabelë, e paracaktuara e së cilës tregon në tunel përpara se të konsultohet tabela kryesore. Një klient VPN me funksion bllokimi ose kill switch mund të bllokojë gjithashtu trafikun që nuk hyn në tunel, pavarësisht se çfarë thotë tabela e rrugëzimit.

VLAN-t e administrimit të rrugëzuara janë rasti tjetër. Nëse administratori është në 192.168.50.0/24 pas ruterit lokal, serveri ka nevojë për një rrugë të qartë për atë parashtesë përmes 192.168.10.1, dhe ajo rrugë duhet t'i mbijetojë një rilidhjeje. Mbajeni përjashtimin specifik për parashtesën e administrimit; një përjashtim i gjerë për intervalet private e zhvlerëson qëllimin e tunelit.

Bëjeni përjashtimin e murit të zjarrit po aq të ngushtë sa rregulli

Nëse hosti drejton një mur zjarri, lejoni SSH vetëm nga burimi i administrimit dhe vetëm në ndërfaqen e LAN-it. Një rregull që lejon portën 22 nga kudo është më i gjerë se kërkesa dhe më i vështirë për t'u justifikuar në një rishikim. Në një host nftables rregulli i takon zinxhirit të hyrjes me ndërfaqen dhe burimin e përputhur; në një host iptables ekuivalenti është një çift përputhjesh në -i dhe -s. Komentojeni rregullin me grupin e administratorëve që i shërben, që auditimi i radhës të mos ketë nevojë të hamendësojë pse porta 22 është e hapur.

Kontrolloni edhe filtrin e vetë klientit VPN. Disa kliente instalojnë rregulla që hedhin poshtë trafikun lokal sipas dizajnit, dhe një rregull i saktë i murit të zjarrit mbi një hedhje në nivel klienti nuk ndryshon asgjë. Lexoni konfigurimin e klientit përpara se të redaktoni murin e zjarrit të hostit, sepse dy filtra në seri prodhojnë një dështim që nuk i ngjan asnjërit prej tyre.

Provoni të dy gjendjet

Ekzekutoni testin dy herë: një herë me tunelin të lidhur dhe një herë me të shkëputur. Në secilën gjendje, konfirmoni dëgjuesin, rrugën dhe një hyrje reale SSH nga makina e administratorit. Një rrugë që funksionon vetëm sa kohë tuneli është lart nuk është rrugë administrimi lokale; është rastësi.

Më pas rinisni tunelin ndërsa një sesion SSH është i hapur. Një sesion që mbijeton dëshmon se rrugëzimi është i qëndrueshëm; një sesion që bie ju tregon se klienti po rishkruan rrugë ose filtra gjatë rilidhjes, gjë që ia vlen të dihet përpara një incidenti dhe jo gjatë tij.

Shënoni adresën e burimit nga e cila testuat, sepse një rregull i shkruar për 192.168.10.50 dështon në heshtje kur laptopi i administratorit kalon në një nënrrjet tjetër.

Shkruani rrugën e rikuperimit në runbook

Vendosni tani çfarë ndodh nëse VPN-ja dalëse prish rrugën lokale. Qasja përmes konsolës, një adresë e dytë administrimi ose një procedurë e dokumentuar për ndalimin e klientit janë të gjitha përgjigje legjitime, dhe cilado prej tyre është më mirë sesa ta zbuloni problemin në momentin kur duhet të hyni. Nëse serveri është në distancë, rruga lokale nuk ekziston, dhe dizajni i saktë është një rrugë e miratuar dhe e veçantë e qasjes në distancë ose një bastion në vend të një porte publike të ekspozuar.

Mbajini dy rolet të ndara në dokumentacion: SSH lokal për administratorin që është afër, dhe tuneli dalës për trafikun e aplikacionit. Kur ato role janë shkruar, një ndryshim i ardhshëm në cilindo prej tyre ka një vend të qartë për t'u kontrolluar, dhe personi tjetër nuk duhet të rizbulojë pse një server me VPN ende përgjigjet në adresën e tij të LAN-it.