Kial fontoporda regulo rompas unu el viaj SSH-vojoj

Du administraj enirejoj sur unu gastiganto, unu servo-pordo kaj politika regulo, kiu devis helpi ambaŭ. La regulo kongruas kun fonta pordo 22, sendas la serĉon al tabelo, kiu konas nur la WAN-aprioran valoron, kaj la VPN-enirejo ĉesas respondi al novaj ensalutoj dum la rekta enirejo daŭre funkcias. Nenio el tio estas mistera, kiam la selektilo estas legata ĝuste. Fonta pordo identigas servon, ne la vojon, per kiu alvenis konekto.

Du enirejoj, unu servo-pordo

La gastiganto havas adreson flanke de LAN kaj VPN-adreson, kaj sshd aŭskultas sur ambaŭ. Rekta seanco kaj tunela seanco do kunhavas la servo-pordon kaj diferencas nur en tio, kiu loka adreso ricevas la konekton.

Tiu diferenco sufiĉas por elekti respondan vojon, kaj ĝi estas ĝuste la diferenco, kiun pordobazita regulo forĵetas. Ambaŭ seancoj produktas respondojn, kies fonta pordo estas 22, do regulo kongruanta kun tiu pordo ne povas apartigi ilin. Ĝi sendas ambaŭ serĉojn al la sama tabelo, kaj unu el ili ricevas respondon, kiu ne taŭgas. La korekto estas kongruigi la atributon, kiu efektive diferencas.

Doni al ĉiu enirejo sian propran pordon ankaŭ funkcius, kaj trakti tion kiel postulon estas dizajna elekto, ne eco de SSH.

Legu la regulon, poste la tabelon

Politika regulo estas ordigita selektilo, kaj la unua, kiu redonas uzeblan respondon, finas la serĉon. Legu la liston laŭ ordo kaj notu, kiu regulo povas venki.

Poste legu la tabelon, al kiu tiu regulo montras, ĉar regulo, kiu solvigas sukcese, ne estas regulo, kiu solvigas utile. Tabelo enhavanta nur aprioran itineron sendas la respondon de VPN el la WAN-interfaco. Pli specifa itinero en posta tabelo neniam estas konsultata, kaj tial aldoni duan tabelon tiel ofte ŝanĝas nenion. La elektita tabelo estas tio, kio devas esti inspektata.

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

Tiuj du eligoj kune klarigas la rezulton; ĉiu sola invitas malĝustan konkludon.

Limigu la regulon al la fluo, kiun vi celas

La atributo, kiu apartigas la du enirejojn, estas la loka fonta adreso. Regulo kongruanta kun tiu adreso sendas nur la tunelajn seancojn al la privata tabelo kaj lasas rektajn seancojn sur la ĉefa tabelo.

Tiu regulo devas esti parigita kun tabelo enhavanta la privatan itineron kaj la revenan vojon por tiu subreto. Limigu ambaŭ al administra trafiko anstataŭ al ĉiu servo sur la gastiganto. Regulo, kiu kaptas ĉiun trafikon de tiu adreso, ankaŭ alidirektos ĉion alian, kion la gastiganto sendas de tie. Mallarĝa venkas inteligentan ĉi tie, ĉar la sekva persono devas legi ĝin.

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

Se ambaŭ enirejoj estas tradukitaj al unu loka adreso, tiu distingo malaperas kaj la dizajno bezonas konek-konscian staton anstataŭe.

Tenu aŭskultanton, permeson kaj respondan elekton aparte

Tri apartaj aferoj devas esti veraj antaŭ ol seanco funkcias: la adreso ekzistas, la servo aŭskultas sur ĝi kaj la respondo trovas sian vojon reen. Itinera ŝanĝo riparas nur la trian.

La agordo de la aŭskultanto estas sia propra dosiero kaj sia propra reŝargo, kaj pluraj aŭskultaj adresoj estas normalaj. Aŭtentigo estas denove tria decido, kaj itinera escepto donas al neniu aliron. Tenu gastigantan ŝlosilan kontrolon, kontan aŭtentigon kaj fontajn limigojn sur ambaŭ enirejoj, kaj rezistu la emon malfortigi la aliajn kontrolojn de la tunelo por ke unu administra vojo funkciu.

Tenu rekuperan kanalon, kiu ne dependas de la vojo, kiun vi ŝanĝas, ĉar eraro ĉi tie ŝlosas la riparon mem.

Pruvu ĝin per nova seanco, ne per malnova

Starigita terminalo pruvas nenion, ĉar ĝi estis akceptita antaŭ la ŝanĝo. Malfermu freŝan seancon tra ĉiu celata enirejo.

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

Poste ripetu la VPN-rekonekton kaj provu denove, ĉar itinero, kiu postvivas rekonekton, ne samas kiel unu aldonita al tabelo, kiun la rekonekto malplenigas. Observu la rifuzitajn fontojn aparte de la permesitaj, por ke blokita provo ne kaŝiĝu malantaŭ funkcianta seanco. Konservu la lokan adreson, la regulon kaj la tabelon apud la rezulto. Se vi anstataŭe dividas la pordojn, registru tion kiel operacian decidon, ne kiel limon de SSH.