Hâld lokaal SSH as de host in útgeande VPN draait

In lytse Linux-tsjinner draait in útgeande VPN foar de applikaasje dy't er hostet, en de administrator wol dy noch altyd fia SSH berikke fan it buroblêd njonken. Dat is in ridlike eask, en it hat meastentiids gjin port-forwarding, gjin adres fan de provider en gjin gat yn 'e tunnel nedich. Wat it nedich hat, is in behearspaad dat mei opsetsin ûntwurpen is ynstee fan erfd út wat de VPN-klant mei de routingstabel die.

De stappen hjirûnder geane derfan út dat de administrator op itselde LAN is.Behear op ôfstân is in oar probleem mei in oar antwurd.

Bind SSH oan it adres dat administrators brûke

Begjin by de listener.ss -ltnp | grep :22 lit sjen wêroan sshd bûn is, en in listener op 0.0.0.0 akseptearret ferbiningen fan elk ynterface, ynklusyf de tunnel. Binen oan it LAN-adres is smeller en makket de bedoeling sichtber:ListenAddress 192.168.10.20 yn sshd_config, folge troch in konfiguraasjetest en in werladen. In typflater yn dat adres is sichtberder as in wildcard, om't sshd wegeret te starten as it adres net bestiet.

Hâld hostkaai-kontrôle en autentikaasje per brûker krekt sa't se binne. „It is allinnich it lokale netwurk“ is gjin autentikaasjemetoade, en in behearkanaal dat de kaai-ferifikaasje oerslacht om't de route koart is, is in behearkanaal dy't wachtet op misbrûk. In DHCP-reservearring of in statysk adres makket it doel foarsisber sûnder it ta de iepenbiere identiteit fan de tsjinner te meitsjen.

Hâld de LAN-route bûten de tunnel

In host mei in adres op 192.168.10.0/24 hat in ferbûne route foar dat foarheaksel, en in mear spesifike route ferslaat de standert fan de VPN yn deselde tabel. Dêrom bliuwt lokaal SSH faak fansels wurkjen as de tunnel omheech komt. Ferifiearje it ynstee fan it oan te nimmen:ip route get 192.168.10.50 neamt it ynterface en it boarne-adres dat de kernel brûke soe, en it antwurd heart it LAN-apparaat te wêzen, net de tunnel. Werhelje de kontrôle ek fan 'e masine fan de administrator, om't syn eigen tabel beslút oft de pakketten ea oankomme. Twa hosts op deselde tried kinne it net iens wêze oer hokker rjochting berikber is.

De oanname brekt op twa plakken. In policy-routing-regel kin ferkear nei in tabel stjoere wêrfan't de standert yn 'e tunnel wiist foardat de haadtabel rieplachte wurdt. In VPN-klant mei in lock-down- of kill-switchfunksje kin ek ferkear blokkearje dat net yn 'e tunnel komt, likegoed wat de routingstabel seit.

Rûtearre behear-VLAN's binne it oare gefal. As de administrator op 192.168.50.0/24 efter de lokale router sit, hat de tsjinner in eksplisite route foar dat foarheaksel fia 192.168.10.1 nedich, en dy route moat in werferbining oerlibje. Hâld de útsûndering spesifyk foar it behearfoarheaksel; in brede útsûndering foar privee-berik ferslaat it doel fan 'e tunnel.

Meitsje de firewall-útsûndering sa smel as it regel

As de host in firewall draait, stean SSH dan allinnich ta fan 'e behearboarne en allinnich op it LAN-ynterface. In regel dy't poarte 22 fan oeral tastean lit, is breder as de eask en hurder te ferantwurdzjen yn in resinsje. Op in nftables-host heart it regel yn 'e input-keatling mei it ynterface en de boarne oerienkommend; op in iptables-host is it ekwivalint in pear oerienkomsten op -i en -s. Kommentearje it regel mei de administratorgroep dy't it tsjinnet, sadat de folgjende audit net riede hoecht wêrom't poarte 22 iepen is.

Kontrolearje ek it eigen filter fan de VPN-klant. Guon klanten ynstallearje regels dy't lokaal ferkear by ûntwerp weismite, en in korrekt firewallregel boppe op in drop op klantnivo feroaret neat. Lês de konfiguraasje fan 'e klant foardat jo de firewall fan 'e host bewurkje, om't twa filters yn searje in fal produsearje dy't op gjin fan beide liket.

Test beide tastannen

Rin de test twa kear: ien kear mei de tunnel ferbûn en ien kear loskeppele. Befêstigje yn elke tastân de listener, de route en in echte SSH-oanmelding fan 'e masine fan de administrator. In paad dat allinnich wurket wylst de tunnel omheech is, is gjin lokaal behearspaad; it is tafal.

Start de tunnel dan opnij wylst in SSH-sesje iepen is. In sesje dy't oerlibbet bewiist dat de routing stabyl is; in sesje dy't falt fertelt jo dat de klant by werferbining routes of filters oerskriuwt, wat it wurdich is om te witten foar in ynsidint ynstee fan derôf.

Skriuw it boarne-adres op dêr't jo fan teste, om't in regel skreaun foar 192.168.10.50 stil mislearret as de laptop fan de administrator nei in oar subnet ferhuzet.

Skriuw it herstelpaad yn 'e runbook

Beslis no wat der bart as de útgeande VPN it lokale paad brekt. Konsoalta tagong, in twadde behearadres of in dokumintearre proseduere om de klant te stopjen binne allegear legitime antwurden, en elk fan dy is better as it probleem te ûntdekken op it momint dat jo oanmelde moatte. As de tsjinner op ôfstân is, bestiet it lokale paad net, en it krekte ûntwerp is in apart goedkard tagongspaad op ôfstân of in bastion ynstee fan in bleatsteld iepenbier port.

Hâld de twa rollen apart yn 'e dokumintaasje: lokaal SSH foar de administrator dy't tichtby is, en de útgeande tunnel foar it ferkear fan 'e applikaasje. As dy rollen opskreaun binne, hat in takomstige feroaring oan ien fan beide in fanselssprekkend plak om kontrolearre te wurden, en de folgjende persoan hoecht net opnij te ûntdekken wêrom't in tsjinner mei in VPN noch altyd antwurdet op syn LAN-adres.