Wêrom't in boarne-poartregel ien fan jo SSH-paden brekt
In "sport 22"-oerienkomst seit net by hokker SSH-yngong in antwurd heart. Behein de beliedsregel ta de behearstream yn stee fan ien tabel allinnich foar WAN.
Twa behearyngongen op ien host, ien tsjinstpoart en in beliedsregel dy't beide helpe moast. De regel past by boarne-poart 22, stjoert it sykjen nei in tabel dy't allinnich de WAN-standert ken, en de VPN-yngong hâldt op mei antwurdzjen op nije oanmeldingen wylst de direkte yngong wurkjen bliuwt. Dêrfan is neat riedseleftich as de selektor goed lêzen wurdt. In boarne-poart identifisearret in tsjinst, net it paad dêr't in ferbining oer oankaam.
Twa yngongen, ien tsjinstpoart
De host hat in adres oan 'e LAN-kant en in VPN-adres, en sshd harket op beide. In direkte sesje en in tunnelsesje diele dêrom de tsjinstpoart en ferskille allinnich yn hokker lokaal adres de ferbining ûntfangt.
Dat ferskil is genôch om in antwurdpaad te kiezen, en it is krekt it ferskil dat in poartbasearre regel weismyt. Beide sesjes meitsje antwurden wêrfan't de boarne-poart 22 is, dus in regel dy't by dy poart past kin se net skiede. Hy stjoert beide sykjen nei deselde tabel, en ien fan beide krijt in antwurd dat net past. De oplossing is om it skaaimerk te passen dat echt ferskilt.
Elke yngong syn eigen poart jaan soe ek wurkje, en dat as eask behannelje is in ûntwerpkar, net in eigenskip fan SSH.
Lês de regel, dan de tabel
In beliedsregel is in oardere selektor, en de earste dy't in brûkber antwurd weromjout einiget it sykjen. Lês de list yn folchoarder en merk op hokker regel winne kin.
Lês dan de tabel dêr't dy regel nei wiist, want in regel dy't mei súkses oplost is net in regel dy't nuttich oplost. In tabel mei allinnich in standertrûte stjoert it antwurd fan 'e VPN troch de WAN-ynterface nei bûten. In krekter rûte yn in lettere tabel wurdt nea rieplachte, en dêrom feroaret it tafoegjen fan in twadde tabel sa faak neat. De keazen tabel is wat ûndersocht wurde moat.
ip -4 rule show
ip route show table 100
ip route show table main
Dy twa útfieringen tegearre ferklearje it resultaat; elk op himsels noadiget in ferkearde konklúzje út.
Behein de regel ta de stream dy't jo bedoele
It skaaimerk dat de twa yngongen skiedt is it lokale boarne-adres. In regel dy't by dat adres past stjoert allinnich de tunnelsesjes nei de partikuliere tabel en lit direkte sesjes op 'e haadtabel.
Dy regel moat pearke wurde mei in tabel dy't de partikuliere rûte en it werompaad foar dat subnet befettet. Behein beide ta behearferkear yn stee fan ta elke tsjinst op 'e host. In regel dy't al it ferkear fan dat adres fangt sil ek al it oare dat de host dêrwei stjoert omliede. Smel ferslaat hjir fernimstich, want de folgjende persoan moat it lêze.
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 beide yngongen nei ien lokaal adres oerset wurde, ferdwynt dat ûnderskied en hat it ûntwerp ferbiningsbewuste tastân nedich yn stee.
Hâld harker, tastimming en antwurdkar apart
Trije aparte dingen moatte wier wêze foardat in sesje wurket: it adres bestiet, de tsjinst harket derop en it antwurd fynt syn paad werom. In rûtferoaring reparearret allinnich it tredde.
Harker-konfiguraasje is syn eigen bestân en syn eigen werladen, en meardere harkadressen binne normaal. Autentikaasje is wer in tredde beslissing, en in rûtêfrûne jout nimmen tagong. Hâld hostkaai-ferifikaasje, akkountautentikaasje en boarnebeheiningen op beide yngongen, en wjerstean de oanstriid om de oare kontrôles fan 'e tunnel te ferswakjen sadat ien behearpaad wurket.
Hâld in werstelkanaal dat net ôfhinklik is fan it paad dat jo feroarje, want in flater hjir slút de reparaasje sels bûten.
Bewiis it mei in nije sesje, net in âlde
In fêstige terminale bewiist neat, want dy waard foar de feroaring talitten. Iepenje in nije sesje fia elke bedoelde yngong.
ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30
Werhelje dan de VPN-ferbining en besykje it opnij, want in rûte dy't in werferbining oerlibbet is net itselde as ien tafoege oan in tabel dy't de werferbining leechmakket. Observearje de wegere boarnen apart fan 'e tastiene, sadat in blokkearre besykjen him net efter in wurkjende sesje ferskûlet. Bewarje it lokale adres, de regel en de tabel neist it resultaat. As jo ynstee de poarten splitsje, registrearje dat as in operasjonele beslissing en net as in beheining fan SSH.