Kodėl šaltinio prievado taisyklė sugriauna vieną iš jūsų SSH kelių

Du valdymo įėjimai viename hostinge, vienas paslaugos prievadas ir politikos taisyklė, kuri turėjo padėti abiem. Taisyklė atitinka šaltinio prievadą 22, siunčia paiešką į lentelę, kuri žino tik WAN numatytąją reikšmę, ir VPN įėjimas nustoja atsakinėti į naujus prisijungimus, o tiesioginis įėjimas veikia toliau. Niekas čia nėra paslaptinga, kai selektorius perskaitomas teisingai. Šaltinio prievadas nurodo paslaugą, o ne kelią, kuriuo atėjo ryšys.

Du įėjimai, vienas paslaugos prievadas

Hostas turi LAN pusės adresą ir VPN adresą, o sshd klausosi abiejų. Todėl tiesioginė sesija ir tunelio sesija dalijasi paslaugos prievadu ir skiriasi tik tuo, kuris vietinis adresas priima ryšį.

Šio skirtumo pakanka atsakymo keliui pasirinkti, ir tai yra būtent tas skirtumas, kurį prievadu pagrįsta taisyklė atmeta. Abi sesijos sukuria atsakymus, kurių šaltinio prievadas yra 22, todėl taisyklė, atitinkanti tą prievadą, negali jų atskirti. Ji siunčia abi paieškas į tą pačią lentelę, ir viena iš jų gauna atsakymą, kuris netinka. Pataisa – suderinti požymį, kuris iš tikrųjų skiriasi.

Kiekvienam įėjimui suteikti savo prievadą taip pat veiktų, o laikyti tai reikalavimu yra dizaino pasirinkimas, o ne SSH savybė.

Perskaitykite taisyklę, tada lentelę

Politikos taisyklė yra tvarkingas selektorius, ir pirmoji, kuri grąžina naudingą atsakymą, baigia paiešką. Perskaitykite sąrašą iš eilės ir atkreipkite dėmesį, kuri taisyklė gali laimėti.

Tada perskaitykite lentelę, į kurią nurodo ta taisyklė, nes sėkmingai išsprendžiama taisyklė nėra taisyklė, kuri išsprendžiama naudingai. Lentelė, kurioje yra tik numatytasis maršrutas, siunčia iš VPN kilusį atsakymą per WAN sąsają į išorę. Konkretesnis maršrutas vėlesnėje lentelėje niekada nenagrinėjamas, ir todėl antros lentelės pridėjimas taip dažnai nieko nekeičia. Pasirinkta lentelė yra tai, ką reikia ištirti.

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

Šie du išvedimai kartu paaiškina rezultatą; kiekvienas atskirai kviečia prie klaidingos išvados.

Apribokite taisyklę srautui, kurį turite omenyje

Požymis, skiriantis du įėjimus, yra vietinis šaltinio adresas. Taisyklė, atitinkanti tą adresą, siunčia tik tunelio sesijas į privačią lentelę, o tiesiogines sesijas palieka pagrindinėje lentelėje.

Ši taisyklė turi būti suporuota su lentele, kurioje yra privatus maršrutas ir to potinklio grįžimo kelias. Apribokite abu valdymo srautui, o ne kiekvienai paslaugai hoste. Taisyklė, kuri pagauna visą srautą iš to adreso, peradresuos ir visa kita, ką hostas iš ten siunčia. Siaura čia nugali gudrų, nes kitas žmogus turi tai perskaityti.

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

Jei abu įėjimai verčiami į vieną vietinį adresą, tas skirtumas išnyksta, ir dizainui vietoj to reikia ryšį suvokiančios būsenos.

Laikykite klausytoją, leidimą ir atsakymo pasirinkimą atskirai

Trys atskiri dalykai turi būti teisingi, kad sesija veiktų: adresas egzistuoja, paslauga jo klausosi, ir atsakymas randa kelią atgal. Maršruto pakeitimas pataiso tik trečiąjį.

Klausytojo konfigūracija yra atskiras failas ir atskiras perkrovimas, ir keli klausymosi adresai yra normalūs. Autentifikavimas vėl yra trečias sprendimas, o maršrutizavimo išimtis niekam nesuteikia prieigos. Išlaikykite hosto rakto tikrinimą, paskyros autentifikavimą ir šaltinio apribojimus abiejuose įėjimuose ir atsispirkite pagundymui susilpninti kitas tunelio kontroles, kad veiktų vienas valdymo kelias.

Laikykite atkūrimo kanalą, kuris nepriklauso nuo kelio, kurį keičiate, nes klaida čia užrakina pačią pataisą.

Įrodykite tai nauja sesija, o ne sena

Nustatytas terminalas nieko neįrodo, nes jis buvo priimtas prieš pakeitimą. Atidarykite naują sesiją per kiekvieną numatytą įėjimą.

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

Tada pakartokite VPN prisijungimą iš naujo ir bandykite dar kartą, nes maršrutas, kuris išlieka po prisijungimo iš naujo, nėra tas pats, kas maršrutas, pridėtas į lentelę, kurią prisijungimas iš naujo išvalo. Stebėkite atmestus šaltinius atskirai nuo leidžiamų, kad užblokuotas bandymas nepaslėptų už veikiančios sesijos. Išsaugokite vietinį adresą, taisyklę ir lentelę šalia rezultato. Jei vietoj to padalijote prievadus, užrašykite tai kaip eksploatacinį sprendimą, o ne kaip SSH apribojimą.