Kāpēc avota porta noteikums salauž vienu no jūsu SSH ceļiem

Divi pārvaldības ieejas vienā resursdatorā, viens pakalpojuma ports un politikas noteikums, kam bija jāpalīdz abām. Noteikums atbilst avota portam 22, sūta meklēšanu uz tabulu, kas zina tikai WAN noklusējumu, un VPN ieeja pārstāj atbildēt uz jaunām pieteikšanām, kamēr tiešā ieeja turpina darboties. Nekas no tā nav noslēpumains, kad selektors tiek izlasīts pareizi. Avota ports identificē pakalpojumu, nevis ceļu, pa kuru ieradās savienojums.

Divas ieejas, viens pakalpojuma ports

Resursdatoram ir LAN puses adrese un VPN adrese, un sshd klausās uz abām. Tāpēc tiešā sesija un tuneļa sesija dala pakalpojuma portu un atšķiras tikai ar to, kura vietējā adrese saņem savienojumu.

Ar šo atšķirību pietiek, lai izvēlētos atbildes ceļu, un tā ir tieši tā atšķirība, ko uz portu balstīts noteikums atmet. Abas sesijas veido atbildes, kuru avota ports ir 22, tāpēc noteikums, kas atbilst šim portam, nevar tās atdalīt. Tas sūta abas meklēšanas uz vienu un to pašu tabulu, un viena no tām saņem atbildi, kas neder. Labojums ir saskaņot atribūtu, kas patiešām atšķiras.

Katram ieejai sava porta piešķiršana arī darbotos, un to uzskatīt par prasību ir dizaina izvēle, nevis SSH īpašība.

Izlasiet noteikumu, pēc tam tabulu

Politikas noteikums ir sakārtots selektors, un pirmais, kas atgriež lietderīgu atbildi, beidz meklēšanu. Izlasiet sarakstu secībā un ievērojiet, kurš noteikums var uzvarēt.

Pēc tam izlasiet tabulu, uz kuru norāda šis noteikums, jo noteikums, kas tiek veiksmīgi atrisināts, nav noteikums, kas tiek atrisināts lietderīgi. Tabula, kurā ir tikai noklusējuma maršruts, sūta no VPN nākušo atbildi ārā pa WAN saskarni. Konkrētāks maršruts vēlākā tabulā nekad netiek apskatīts, un tāpēc otrās tabulas pievienošana tik bieži neko nemaina. Izvēlētā tabula ir tas, kas jāpārbauda.

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

Šie divi izvadi kopā izskaidro rezultātu; katrs atsevišķi aicina uz nepareizu secinājumu.

Ierobežojiet noteikumu ar plūsmu, ko domājat

Atribūts, kas atdala abas ieejas, ir vietējā avota adrese. Noteikums, kas atbilst šai adresei, sūta tikai tuneļa sesijas uz privāto tabulu un atstāj tiešās sesijas galvenajā tabulā.

Šis noteikums ir jāsapāro ar tabulu, kurā ir privātais maršruts un šī apakštīkla atgriešanās ceļš. Ierobežojiet abus ar pārvaldības trafiku, nevis ar katru resursdatora pakalpojumu. Noteikums, kas uztver visu trafiku no šīs adreses, novirzīs arī visu pārējo, ko resursdators no turienes sūta. Šaurais šeit uzvar gudro, jo nākamajam cilvēkam tas jāizlasa.

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

Ja abas ieejas tiek pārtulkotas uz vienu vietējo adresi, šī atšķirība pazūd, un dizainam tā vietā vajadzīgs savienojumu apzināts stāvoklis.

Turiet klausītāju, atļauju un atbildes izvēli atsevišķi

Trim atsevišķām lietām jābūt patiesām, pirms sesija darbojas: adrese pastāv, pakalpojums tajā klausās, un atbilde atrod ceļu atpakaļ. Maršruta maiņa labo tikai trešo.

Klausītāja konfigurācija ir atsevišķs fails un atsevišķa pārlāde, un vairākas klausīšanās adreses ir normālas. Autentifikācija atkal ir trešais lēmums, un maršrutēšanas izņēmums nevienam nepiešķir piekļuvi. Saglabājiet resursdatora atslēgas pārbaudi, konta autentifikāciju un avota ierobežojumus abās ieejās, un pretojieties vēlmei vājināt pārējās tuneļa kontroles, lai darbotos viens pārvaldības ceļš.

Turiet atkopšanas kanālu, kas nav atkarīgs no ceļa, kuru maināt, jo kļūda šeit bloķē pašu labojumu.

Pierādiet to ar jaunu sesiju, nevis vecu

Izveidots terminālis neko nepierāda, jo tas tika uzņemts pirms izmaiņām. Atveriet jaunu sesiju pa katru paredzēto ieeju.

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

Pēc tam atkārtojiet VPN atkārtotu savienošanu un mēģiniet vēlreiz, jo maršruts, kas pārdzīvo atkārtotu savienošanu, nav tas pats, kas maršruts, kas pievienots tabulai, kuru atkārtotā savienošana iztīra. Novērojiet noraidītos avotus atsevišķi no atļautajiem, lai bloķēts mēģinājums nepaslēptos aiz strādājošas sesijas. Saglabājiet vietējo adresi, noteikumu un tabulu blakus rezultātam. Ja tā vietā sadalījāt portus, pierakstiet to kā ekspluatācijas lēmumu, nevis kā SSH ierobežojumu.