Waarom 'n bronpoort-reël een van jou SSH-paaie breek

Twee bestuursinskrywings op een gasheer, een dienspoort, en 'n beleidsreël wat albei moes help. Die reël pas by bronpoort 22, stuur die opsoek na 'n tabel wat net die WAN-verstek ken, en die VPN-inskrywing hou op om nuwe aanmeldings te beantwoord terwyl die direkte inskrywing bly werk. Niks daarvan is raaiselagtig sodra die kieser behoorlik gelees word nie. 'n Bronpoort identifiseer 'n diens, nie die pad waarlangs 'n verbinding aangekom het nie.

Twee inskrywings, een dienspoort

Die gasheer het 'n adres aan die LAN-kant en 'n VPN-adres, en sshd luister op albei. 'n Direkte sessie en 'n tonnelsessie deel dus die dienspoort en verskil net in watter plaaslike adres die verbinding ontvang.

Daardie verskil is genoeg om 'n antwoordpad te kies, en dit is presies die verskil wat 'n poortgebaseerde reël weggooi. Albei sessies lewer antwoorde waarvan die bronpoort 22 is, so 'n reël wat daardie poort pas, kan hulle nie skei nie. Dit stuur albei opsoeke na dieselfde tabel, en een van hulle kry 'n antwoord wat nie pas nie. Die oplossing is om die eienskap te pas wat werklik verskil.

Om elke inskrywing sy eie poort te gee, sou ook werk, en om dit as 'n vereiste te beskou, is 'n ontwerpkeuse eerder as 'n eienskap van SSH.

Lees die reël, dan die tabel

'n Beleidsreël is 'n geordende kieser, en die eerste een wat 'n bruikbare antwoord gee, beëindig die opsoek. Lees die lys in volgorde en let op watter reël kan wen.

Lees dan die tabel waarna daardie reël wys, want 'n reël wat suksesvol oplos, is nie 'n reël wat nuttig oplos nie. 'n Tabel met net 'n verstekroete stuur die antwoord van die VPN deur die WAN-koppelvlak uit. 'n Meer spesifieke roete in 'n latere tabel word nooit geraadpleeg nie, en daarom verander die byvoeg van 'n tweede tabel so dikwels niks. Die gekose tabel is die ding wat ondersoek moet word.

ip -4 rule show
ip route show table 100
ip route show table main

Daardie twee uitsette verduidelik saam die resultaat; enige een alleen nooi 'n verkeerde gevolgtrekking uit.

Beperk die reël tot die vloei wat jy bedoel

Die eienskap wat die twee inskrywings skei, is die plaaslike bronadres. 'n Reël wat daardie adres pas, stuur net die tonnelsessies na die private tabel en laat direkte sessies op die hooftabel.

Daardie reël moet met 'n tabel gepaar word wat die private roete en die terugpad vir daardie subnet bevat. Beperk albei tot bestuursverkeer eerder as tot elke diens op die gasheer. 'n Reël wat alle verkeer van daardie adres vang, sal ook enigiets anders wat die gasheer daarvan stuur, herlei. Smal klop hier vir slim, want die volgende persoon moet dit lees.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

As albei inskrywings op een plaaslike adres vertaal word, verdwyn daardie onderskeid en het die ontwerp verbindingsbewuste toestand nodig eerder.

Hou luisteraar, toestemming en antwoordkeuse apart

Drie afsonderlike dinge moet waar wees voordat 'n sessie werk: die adres bestaan, die diens luister daarop, en die antwoord vind sy pad terug. 'n Roeteverandering maak net die derde reg.

Luisteraarkonfigurasie is sy eie lêer en sy eie herlaai, en meerdere luisteradresse is normaal. Verifikasie is weer 'n derde besluit, en 'n roete-uitsondering gee niemand toegang nie. Hou gasheerklawerifikasie, rekeningverifikasie en bronbeperkings op albei inskrywings, en weerstaan die drang om die tonnel se ander kontroles te verswak sodat een bestuurspad werk.

Hou 'n herstelkanaal wat nie van die pad wat jy verander, afhang nie, want 'n fout hier sluit die herstel uit.

Bewys dit met 'n nuwe sessie, nie 'n ou een nie

'n Gevestigde terminaal bewys niks, want dit is voor die verandering toegelaat. Maak 'n vars sessie deur elke beoogde inskrywing oop.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Herhaal dan die VPN-herverbinding en probeer weer, want 'n roete wat 'n herverbinding oorleef, is nie dieselfde as een wat by 'n tabel gevoeg is wat die herverbinding leegmaak nie. Let die geweierde bronne apart van die toegelate op, sodat 'n geblokkeerde poging nie agter 'n werkende sessie wegkruip nie. Stoor die plaaslike adres, die reël en die tabel langs die resultaat. As jy eerder die poorte splits, teken dit as 'n bedryfsbesluit aan eerder as 'n beperking van SSH.