Kaks haldussisendit ühel hostil, üks teenuseport ja poliitikareegel, mis pidi aitama mõlemat. Reegel sobib lähteportiga 22, saadab otsingu tabelisse, mis teab ainult WAN-i vaikeväärtust, ja VPN-sisend lakkab uutele sisselogimistele vastamast, samal ajal kui otsesisend töötab edasi. Miski selles pole mõistatuslik, kui selektorit õigesti lugeda. Lähteport tähistab teenust, mitte teed, mida mööda ühendus saabus.

Kaks sisendit, üks teenuseport

Hostil on LAN-i poolne aadress ja VPN-aadress ning sshd kuulab mõlemal. Seetõttu jagavad otsene seanss ja tunneliseanss teenuseporti ning erinevad ainult selle poolest, milline kohalik aadress ühenduse vastu võtab.

See erinevus on piisav vastusteekonna valimiseks ja see on täpselt see erinevus, mille portipõhine reegel kõrvale jätab. Mõlemad seansid loovad vastuseid, mille lähteport on 22, seega ei saa selle pordiga sobiv reegel neid eristada. See saadab mõlemad otsingud samasse tabelisse ja üks neist saab vastuse, mis ei sobi. Parandus on sobitada atribuut, mis tegelikult erineb.

Iga sisendi jaoks oma pordi andmine töötaks samuti, ja selle nõudeks pidamine on disainivalik, mitte SSH omadus.

Lugege reeglit, seejärel tabelit

Poliitikareegel on järjestatud selektor ja esimene, mis tagastab kasutatava vastuse, lõpetab otsingu. Lugege loendit järjekorras ja pange tähele, milline reegel võib võita.

Seejärel lugege tabelit, millele see reegel osutab, sest edukalt lahenev reegel ei ole veel kasulikult lahenev reegel. Ainult vaikimisi marsruuti sisaldav tabel saadab VPN-ist lähtuva vastuse WAN-liidesest välja. Hilisemas tabelis olevat täpsemat marsruuti ei vaadata kunagi ja seetõttu ei muuda teise tabeli lisamine nii sageli midagi. Valitud tabel on see, mida tuleb uurida.

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

Need kaks väljundit koos selgitavad tulemust; kumbki üksi kutsub esile vale järelduse.

Piirake reegel voole, mida mõtlete

Atribuut, mis kaks sisendit eraldab, on kohalik lähteaadress. Selle aadressiga sobiv reegel saadab ainult tunneliseansid privaatsesse tabelisse ja jätab otsesed seansid põhitabelisse.

See reegel tuleb siduda tabeliga, mis sisaldab privaatset marsruuti ja selle alamvõrgu tagasiteed. Piirake mõlemad haldusliiklusele, mitte hosti igale teenusele. Reegel, mis püüab kogu sellelt aadressilt tuleva liikluse, suunab ümber ka kõik muu, mida host sealt saadab. Kitsas võidab siin nutika, sest järgmine inimene peab seda lugema.

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

Kui mõlemad sisendid tõlgitakse ühele kohalikule aadressile, kaob see erinevus ja disain vajab selle asemel ühendusest teadlikku olekut.

Hoidke kuulaja, luba ja vastusevalik eraldi

Enne kui seanss töötab, peavad tõele vastama kolm eraldi asja: aadress on olemas, teenus kuulab sellel ja vastus leiab tee tagasi. Marsruudi muutmine parandab ainult kolmanda.

Kuulaja konfiguratsioon on omaette fail ja omaette uuestilaadimine ning mitu kuulamisadressi on normaalsed. Autentimine on jälle kolmas otsus ja marsruutimiserand ei anna kellelegi juurdepääsu. Hoidke hostivõtme kontroll, konto autentimine ja lähtepiirangud mõlemal sisendil ning vastustage kiusatust nõrgendada tunneli muid kontrolle, et üks haldustee toimiks.

Hoidke taastamise kanalit, mis ei sõltu teest, mida muudate, sest viga siin lukustab paranduse enda välja.

Tõestage seda uue seansiga, mitte vanaga

Sisselogitud terminal ei tõesta midagi, sest see lubati enne muudatust. Avage värske seanss iga kavandatud sisendi kaudu.

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

Seejärel korrake VPN-i taasthendust ja proovige uuesti, sest taasthendusele vastu pidav marsruut ei ole sama, mis tabelisse lisatud marsruut, mille taasthendus tühjendab. Jälgige keelatud allikaid lubatutest eraldi, et blokeeritud katse ei peituks töötava seansi taga. Salvestage kohalik aadress, reegel ja tabel tulemuse kõrvale. Kui jagate selle asemel pordid, kirjutage see üles tööotsusena, mitte SSH-i piiranguna.

Seotud artiklid