Pse një rregull porti burimor thyen një nga rrugët e tua SSH

Dy hyrje menaxhimi në një host të vetëm, një port shërbimi dhe një rregull politike që duhej t'i ndihmonte të dyja. Rregulli përputhet me portin burimor 22, e dërgon kërkimin në një tabelë që njeh vetëm vlerën e paracaktuar të WAN, dhe hyrja VPN ndalon së përgjigjuri për hyrjet e reja ndërsa hyrja e drejtpërdrejtë vazhdon të punojë. Asgjë nga kjo nuk është misterioze sapo zgjedhësi lexohet si duhet. Një port burimor identifikon një shërbim, jo rrugën nga e cila erdhi një lidhje.

Dy hyrje, një port shërbimi

Host-i ka një adresë nga ana LAN dhe një adresë VPN, dhe sshd dëgjon në të dyja. Prandaj një sesion i drejtpërdrejtë dhe një sesion tuneli ndajnë portin e shërbimit dhe ndryshojnë vetëm në atë se cila adresë lokale e pranon lidhjen.

Ky ndryshim mjafton për të zgjedhur një rrugë përgjigjeje, dhe është pikërisht ndryshimi që një rregull i bazuar në port e hedh poshtë. Të dyja sesionet prodhojnë përgjigje porti burimor i të cilave është 22, ndaj një rregull që përputhet me atë port nuk mund t'i ndajë ato. I dërgon të dyja kërkimet në të njëjtën tabelë, dhe njëra prej tyre merr një përgjigje që nuk përshtatet. Rregullimi është të përputhet atributi që ndryshon vërtet.

T'i japësh çdo hyrje portin e vet do të funksiononte gjithashtu, dhe ta trajtosh atë si kërkesë është zgjedhje projektimi, jo veti e SSH.

Lexo rregullin, pastaj tabelën

Një rregull politike është një zgjedhës i renditur, dhe i pari që kthen një përgjigje të përdorshme e përfundon kërkimin. Lexo listën sipas radhës dhe vër re se cili rregull mund të fitojë.

Pastaj lexo tabelën që tregon ai rregull, sepse një rregull që zgjidhet me sukses nuk është një rregull që zgjidhet në mënyrë të dobishme. Një tabelë që përmban vetëm një rrugë të paracaktuar e dërgon përgjigjen me origjinë VPN jashtë përmes ndërfaqes WAN. Një rrugë më specifike në një tabelë të mëvonshme nuk konsultohet kurrë, dhe për këtë arsye shtimi i një tabele të dytë kaq shpesh nuk ndryshon asgjë. Tabela e zgjedhur është ajo që duhet ekzaminuar.

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

Këto dy dalje së bashku e shpjegojnë rezultatin; secila veç e vetme fton në një përfundim të gabuar.

Kufizo rregullin në rrjedhën që ke ndër mend

Atributi që i ndan dy hyrjet është adresa burimore lokale. Një rregull që përputhet me atë adresë i dërgon vetëm sesionet e tunelit në tabelën private dhe i lë sesionet e drejtpërdrejta në tabelën kryesore.

Ai rregull duhet të çiftohet me një tabelë që përmban rrugën private dhe rrugën e kthimit për atë nënrrjet. Kufizo të dyja në trafikun e menaxhimit në vend të çdo shërbimi në host. Një rregull që kap të gjithë trafikun nga ajo adresë do të ridrejtojë edhe çdo gjë tjetër që host-i dërgon prej andej. E ngushta e mund të zgjuarën këtu, sepse personi tjetër duhet ta lexojë.

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

Nëse të dyja hyrjet përkthehen në një adresë të vetme lokale, ai dallim zhduket dhe projektimi ka nevojë në vend të tij për gjendje që e njeh lidhjen.

Mbaj të ndara dëgjuesin, lejen dhe zgjedhjen e përgjigjes

Tre gjëra të ndara duhet të jenë të vërteta përpara se një sesion të funksionojë: adresa ekziston, shërbimi dëgjon në të, dhe përgjigja e gjen rrugën e kthimit. Një ndryshim rruge rregullon vetëm të tretën.

Konfigurimi i dëgjuesit është skedar i vet dhe ringarkim i vet, dhe disa adresa dëgjimi janë normale. Vërtetimi është përsëri një vendim i tretë, dhe një përjashtim rrugëtimi nuk i jep askujt akses. Mbaj verifikimin e çelësit të host-it, vërtetimin e llogarisë dhe kufizimet e burimit në të dyja hyrjet, dhe kundërshto dëshirën për të dobësuar kontrollet e tjera të tunelit që një rrugë e vetme menaxhimi të funksionojë.

Mbaj një kanal rikuperimi që nuk varet nga rruga që po ndryshon, sepse një gabim këtu bllokon vetë rregullimin.

Provo me një sesion të re, jo me një të vjetër

Një terminal i vendosur nuk provon asgjë, pasi u pranua përpara ndryshimit. Hap një sesion të re përmes çdo hyrjeje të synuar.

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

Pastaj përsërit rilidhjen e VPN dhe provo përsëri, sepse një rrugë që i mbijeton një rilidhjeje nuk është e njëjtë me një të shtuar në një tabelë që rilidhja e zbraz. Vëzhgo burimet e refuzuara veçmas nga ato të lejuara, që një përpjekje e bllokuar të mos fshihet pas një sesioni që punon. Ruaj adresën lokale, rregullin dhe tabelën pranë rezultatit. Nëse në vend të kësaj i ndan portet, regjistroje atë si vendim operativ dhe jo si kufi i SSH.