SSH otrajā privātajā ceļā, kamēr VPN paliek ieslēgts
SSH dēmons, kas piesaistīts tuneļa adresei, neatbildēs jaunā privātā saskarnē. Pievienojiet piesaisti un pārbaudiet jaunu sesiju pirms vecās aizvēršanas.
Viena iekārta sasniedz otru caur VPN, un tagad kāds vēlas to pašu čaulu pakalpojumu sniedzēja privātajā tīklā. Maršruts pastāv, ping izdodas, bet SSH joprojām atsakās. Parastais iemesls ir tāds, ka dēmons nekad nav klausījies jaunajā adresē, tāpēc nav kam pieslēgties. Tā ir adreses piesaistes problēma, pirms tā kļūst par ugunsmūra problēmu.
Kāpēc jauns maršruts neizveido jaunu klausītāju
Klausošo ligzdu izveido process, kas nosauc adreses, kurās tas pieņems savienojumus. Maršruts tikai pasaka paketēm, kurp doties; tas neizveido klausītāju galamērķī. Kad sshd konfigurēts ar vienu ListenAddress, savienojumi uz jebkuru citu vietējo adresi tiek noraidīti, lai gan saskarne darbojas. Tas pats attiecas uz ligzdas vienību, kurai pieder ports, tāpēc pirmā pārbaude vienmēr ir tas, kas patiešām klausās.
Salīdziniet abus ceļus pēc galamērķa adreses, nevis pēc saskarnes nosaukuma. Klients pieslēdzas adresei, un šai adresei jābūt piesaistītai, pirms jebkurš ugunsmūra noteikums kļūst svarīgs.
Uzskaitiet adreses un klausītājus
Pirms kaut ko rediģējat, pierakstiet resursdatora adreses un ligzdas, kas pastāv tagad.
ip -br addr
ss -ltnp | grep ':22'Adrešu saraksts parāda, kura privātā adrese ir īsta un kurā saskarnē, bet ligzdu saraksts parāda, vai kaut kas tai ir piesaistīts. Klausītājs uz 0.0.0.0:22 jau pieņem visas adreses, tāpēc jauna piesaiste neko nepievieno. Klausītājs uz vienas konkrētas adreses uzreiz izskaidro atteikumu. Ja ports pieder ligzdas vienībai, nevis dēmonam, dēmona konfigurācija nav viss stāsts.
Pievienojiet piesaisti un saglabājiet veco
OpenSSH pieņem vairākus ListenAddress ierakstus, tāpēc VPN ceļš var palikt, kamēr tiek pievienots privātais. Pārbaudiet failu pirms tā pārlādes.
sshd -t
systemctl reload sshdNeizdevies konfigurācijas tests atstāj darbojošos dēmonu neskartu, un tieši to jūs vēlaties, kamēr esat savienots pa ceļu, kuru rediģējat. Saglabājiet esošo ierakstu, pievienojiet jauno vietējo adresi un apstipriniet, ka pakalpojums tiek pārlādēts, nepārtraucot pašreizējo sesiju. Ligzdas aktivizētos instalācijās pievienojiet adresi ligzdas vienībai un pārlādējiet šo vienību. Pēc tam vēlreiz izlasiet klausītāju sarakstu, jo piesaiste, kas tā arī neparādījās, nozīmē, ka rediģēts nepareizais komponents.
Pārbaudiet jauno sesiju pirms vecās aizvēršanas
Pieslēdzieties jaunajai adresei, kamēr sākotnējā sesija vēl ir atvērta, un izmantojiet detalizētu izvadi, lai redzētu, kura adrese un atslēga tika izmantota. Atstājiet sākotnējo sesiju atvērtu, līdz pārbaude izdodas divreiz.
ssh -v [email protected]Izlasiet atkļūdošanas rindas par galamērķa adresi un uzrādīto resursdatora atslēgu. Salīdziniet resursdatora atslēgas nospiedumu ar vērtību, kurai jau uzticaties, nevis pieņemiet nezināmu atslēgu tāpēc, ka tīkls aprakstīts kā privāts. Jaunajam galamērķim nepieciešams savs known_hosts ieraksts, un tas ir gaidīts. Veco pārvaldības sesiju vajadzētu aizvērt tikai tad, kad privātais ceļš darbojas.
SSH aizsargā pārsūtīšanu, bet atsevišķi tas nepadara divus tīklus līdzvērtīgus. Izlemiet, vai privātā tranzīta uzticība atbilst datiem, pirms paļaujaties uz to.