Hou plaaslike SSH terwyl die gasheer ’n uitgaande VPN gebruik

’n Klein Linux-bediener gebruik ’n uitgaande VPN vir die toepassing wat hy huisves, en die administrateur wil dit steeds per SSH vanaf die kantoor langsaan bereik. Dit is ’n redelike vereiste, en dit benodig gewoonlik geen poortdeurvoer, geen verskafferadres en geen gat in die tonnel nie. Wat dit nodig het, is ’n bestuurspad wat doelbewus ontwerp is in plaas van geërf uit wat die VPN-kliënt ook al met die roetetabel gedoen het.

Die stappe hieronder veronderstel dat die administrateur op dieselfde LAN is.Afgeleë administrasie is ’n ander probleem met ’n ander antwoord.

Bind SSH aan die adres wat administrateurs gebruik

Begin by die luisteraar.ss -ltnp | grep :22 wys waaraan sshd gebind is, en ’n luisteraar op 0.0.0.0 aanvaar verbindings van elke koppelvlak, insluitend die tonnel. Om aan die LAN-adres te bind is nouer en maak die bedoeling sigbaar:ListenAddress 192.168.10.20 in sshd_config, gevolg deur ’n konfigurasietoets en ’n herlaai. ’n Tikfout in daardie adres is meer sigbaar as ’n wildcard, want sshd weier om te begin wanneer die adres nie bestaan nie.

Behou gasheer-sleutelkontrole en per-gebruiker-verifikasi presies soos dit is. “Dit is net die plaaslike netwerk” is nie ’n verifikasiesmetode nie, en ’n bestuurskanaal wat sleutelverifikasie oorslaan omdat die roete kort is, is ’n bestuurskanaal wat wag om misbruik te word. ’n DHCP-reservering of ’n statiese adres maak die teiken voorspelbaar sonder om dit in die bediener se openbare identiteit te verander.

Hou die LAN-roete uit die tonnel

’n Gasheer met ’n adres op 192.168.10.0/24 het ’n gekoppelde roete vir daardie voorvoegsel, en ’n meer spesifieke roete klop die VPN se verstek binne dieselfde tabel. Dit is waarom plaaslike SSH dikwels vanself bly werk wanneer die tonnel opkom. Verifieer dit eerder as om dit te aanvaar:ip route get 192.168.10.50 wys die koppelvlak en bronadres wat die kern sou gebruik, en die antwoord moet die LAN-toestel wees, nie die tonnel nie. Herhaal die kontrole ook vanaf die administrateur se masjien, want sy eie tabel besluit of die pakkette ooit aankom. Twee gashere op dieselfde draad kan verskil oor watter rigting bereikbaar is.

Die aanname breek op twee plekke. ’n Beleidsroeteringsreël kan verkeer na ’n tabel stuur waarvan die verstek in die tonnel wys voordat die hoof-tabel geraadpleeg word. ’n VPN-kliënt met ’n grendel- of doodskakelaar-funksie kan ook verkeer blokkeer wat nie die tonnel binnegaan nie, ongeag wat die roetetabel sê.

Gerouteerde bestuurs-VLAN's is die ander geval. As die administrateur op 192.168.50.0/24 agter die plaaslike roeteerder sit, het die bediener ’n eksplisiete roete vir daardie voorvoegsel deur 192.168.10.1 nodig, en daardie roete moet ’n herverbinding oorleef. Bly die uitsondering spesifiek vir die bestuursvoorvoegsel; ’n breë uitsondering vir private reekse verydel die doel van die tonnel.

Maak die brandmuur-uitsondering so nou soos die reël

As die gasheer ’n brandmuur het, laat SSH net vanaf die bestuursbron toe, en net op die LAN-koppelvlak. ’n Reël wat poort 22 van orals toelaat, is breër as die vereiste en moeiliker om in ’n oorsig te regverdig. Op ’n nftables-gasheer hoort die reël in die invoerketting met die koppelvlak en bron gematch; op ’n iptables-gasheer is die ekwivalent ’n paar passings op -i en -s. Kommentaar die reël met die administrateurgroep wat dit dien, sodat die volgende oudit nie hoef te raai waarom poort 22 oop is nie.

Kontroleer ook die VPN-kliënt se eie filter. Sommige kliënte installeer reëls wat plaaslike verkeer by ontwerp laat val, en ’n korrekte brandmuurreël bo-op ’n kliëntvlak-verwerping verander niks nie. Lees die kliënt se konfigurasie voordat jy die gasheer se brandmuur wysig, want twee filters in serie lewer ’n fout wat soos nie een van hulle lyk nie.

Toets albei toestande

Voer die toets twee keer uit: een keer met die tonnel verbind en een keer met dit ontkoppel. Bevestig in elke toestand die luisteraar, die roete en ’n werklike SSH-aanmelding vanaf die administrateur se masjien. ’n Pad wat net werk terwyl die tonnel op is, is nie ’n plaaslike bestuurspad nie; dit is ’n toeval.

Herbegin dan die tonnel terwyl ’n SSH-sessie oop is. ’n Sessie wat oorleef bewys die roetering is stabiel; ’n sessie wat val, sê vir jou die kliënt herskryf roetes of filters met herverbinding, wat die moeite werd is om voor ’n voorval te weet eerder as tydens een.

Teken die bronadres aan waarvandaan jy getoets het, want ’n reël wat vir 192.168.10.50 geskryf is, misluk stil wanneer die administrateur se skootrekenaar na ’n ander subnet skuif.

Skryf die herstelpad in die runbook

Besluit nou wat gebeur as die uitgaande VPN die plaaslike pad breek. Konsoltoegang, ’n tweede bestuursadres of ’n gedokumenteerde prosedure om die kliënt te stop is almal geldige antwoorde, en enige een daarvan is beter as om die probleem te ontdek op die oomblik wat jy moet aanmeld. As die bediener op ’n afstand is, bestaan die plaaslike pad nie, en die korrekte ontwerp is ’n aparte goedgekeurde afgeleë-toegangroete of ’n bastion eerder as ’n blootgestelde openbare poort.

Hou die twee rolle apart in die dokumentasie: plaaslike SSH vir die administrateur wat naby is, en die uitgaande tonnel vir die toepassing se verkeer. Wanneer daardie rolle neergeskryf is, het ’n toekomstige verandering aan enige een ’n ooglopende plek om nagegaan te word, en die volgende persoon hoef nie te herontdek waarom ’n bediener met ’n VPN steeds op sy LAN-adres antwoord nie.