Konservu lokan SSH kiam la gastiganto uzas elirantan VPN

Malgranda Linux-servilo uzas elirantan VPN por la aplikaĵo, kiun ĝi gastigas, kaj la administranto ankoraŭ volas atingi ĝin per SSH de la apuda skribotablo. Tio estas racia postulo, kaj ĝi kutime bezonas nek pordvadon, nek provizadan adreson, nek truon en la tunelo. Kion ĝi bezonas, estas administra vojo desegnita intence anstataŭ heredita de tio, kion la VPN-kliento faris al la enkursiga tabelo.

La subaj paŝoj supozas, ke la administranto estas en la sama LAN.Fora administrado estas alia problemo kun alia respondo.

Ligu SSH al la adreso, kiun administrantoj uzas

Komencu ĉe la aŭskultanto.ss -ltnp | grep :22 montras, al kio sshd estas ligita, kaj aŭskultanto sur 0.0.0.0 akceptas konektojn de ĉiu interfaco, inkluzive de la tunelo. Ligi al la LAN-adreso estas pli mallarĝa kaj igas la intencon videbla:ListenAddress 192.168.10.20 en sshd_config, sekvata de konfigura testado kaj reload. Tajperaro en tiu adreso estas pli videbla ol ĵokero, ĉar sshd rifuzas starti, kiam la adreso ne ekzistas.

Konservu la kontrolon de gastiga ŝlosilo kaj la uzantobazan aŭtentikigon ĝuste tiaj, kiaj ili estas. „Estas nur la loka reto“ ne estas aŭtentikiga metodo, kaj administra kanalo, kiu preterlasas ŝlosilan kontrolon ĉar la vojo estas mallonga, estas administra kanalo atendanta misuzon. DHCP-rezervo aŭ statika adreso igas la celon antaŭvidebla sen igi ĝin la publika identeco de la servilo.

Tenu la LAN-vojon ekster la tunelo

Gastiganto kun adreso en 192.168.10.0/24 havas konektitan vojon por tiu prefikso, kaj pli specifa vojo venkas la defaŭltan de la VPN ene de la sama tabelo. Tial loka SSH ofte daŭre funkcias per si mem, kiam la tunelo leviĝas. Kontrolu tion anstataŭ supozi:ip route get 192.168.10.50 nomas la interfacon kaj fontadreson, kiujn la kerno uzus, kaj la respondo devus esti la LAN-aparato, ne la tunelo. Ripetu la kontrolon ankaŭ de la maŝino de la administranto, ĉar ĝia propra tabelo decidas, ĉu la pakaĵoj iam alvenas. Du gastigantoj sur la sama drato povas malkonsenti pri tio, kiu direkto estas atingebla.

La supozo rompiĝas en du lokoj. Politika enkursiga regulo povas sendi trafikon al tabelo, kies defaŭlto montras en la tunelon, antaŭ ol la ĉefa tabelo estas konsultita. VPN-kliento kun ŝlosa aŭ kill-switch-funkcio ankaŭ povas bloki trafikon, kiu ne eniras la tunelon, sendepende de tio, kion diras la enkursiga tabelo.

Enkursigitaj administraj VLAN-oj estas la alia kazo. Se la administranto sidas sur 192.168.50.0/24 malantaŭ la loka enkursigilo, la servilo bezonas eksplicitan vojon por tiu prefikso tra 192.168.10.1, kaj tiu vojo devas postvivi rekonekton. Tenu la escepton specifa por la administra prefikso; larĝa escepto por privataj intervaloj fiaskigas la celon de la tunelo.

Faru la fajroŝirma escepto same mallarĝa kiel la regulo

Se la gastiganto uzas fajroŝirmon, permesu SSH nur de la administra fonto kaj nur sur la LAN-interfaco. Regulo, kiu permesas pordon 22 de ie ajn, estas pli larĝa ol la postulo kaj pli malfacile pravigebla en revizio. Sur nftables-gastiganto la regulo apartenas al la eniga ĉeno kun interfaco kaj fonto kongruaj; sur iptables-gastiganto la ekvivalento estas paro da kongruoj sur -i kaj -s. Komentu la regulon per la administra grupo, kiun ĝi servas, por ke la sekva revizio ne devu diveni, kial pordo 22 estas malfermita.

Kontrolu ankaŭ la propran filtrilon de la VPN-kliento. Iuj klientoj instalas regulojn, kiuj laŭdezajne forĵetas lokan trafikon, kaj ĝusta fajroŝirma regulo super klientnivela forĵeto ŝanĝas nenion. Legu la konfiguraĵon de la kliento antaŭ ol redakti la fajroŝirmon de la gastiganto, ĉar du filtriloj en serio produktas malsukceson, kiu similas al nek unu nek la alia.

Testu ambaŭ statojn

Rulu la teston dufoje: unufoje kun la tunelo konektita kaj unufoje kun ĝi malkonektita. En ĉiu stato konfirmu la aŭskultanton, la vojon kaj realan SSH-ensaluton de la maŝino de la administranto. Vojo, kiu funkcias nur dum la tunelo estas supre, ne estas loka administra vojo; ĝi estas koincido.

Poste restartigu la tunelon dum SSH-sesio estas malfermita. Sesio, kiu postvivas, pruvas, ke la enkursigado estas stabila; sesio, kiu falas, diras al vi, ke la kliento reŝkribas vojojn aŭ filtrilojn ĉe rekonekto, kion indas scii antaŭ incidento, ne dum ĝi.

Notu la fontadreson, de kiu vi testis, ĉar regulo skribita por 192.168.10.50 malsukcesas silente, kiam la tekokomputilo de la administranto translokiĝas al alia subreto.

Skribu la reakiran vojon en la runbook

Decidu nun, kio okazas, se la eliranta VPN rompas la lokan vojon. Konsola aliro, dua administra adreso aŭ dokumentita proceduro por haltigi la klienton estas ĉiuj legitimaj respondoj, kaj iu ajn el ili estas pli bona ol malkovri la problemon en la momento, kiam vi bezonas ensaluti. Se la servilo estas fora, la loka vojo ne ekzistas, kaj la ĝusta dezajno estas aparta aprobita fora aliro-vojo aŭ bastiono anstataŭ elmetita publika pordo.

Tenu la du rolojn apartaj en la dokumentaro: loka SSH por la administranto, kiu estas proksime, kaj la eliranta tunelo por la trafiko de la aplikaĵo. Kiam tiuj roloj estas skribitaj, estonta ŝanĝo al iu ajn el ili havas evidentan lokon por kontroli, kaj la sekva persono ne devas remalkovri, kial servilo kun VPN ankoraŭ respondas sur sia LAN-adreso.