Pilnas tunelis užmušė jūsų SSH sesiją: prisekite grįžimo maršrutą
Pilnas tunelis pagauna ir atsakymus į jūsų pačių SSH sesiją. Prisekite host maršrutą savo administravimo adresui per senąjį šliuzą ir iš naujo įdiekite jį prisijungus.
Paleiskite OpenVPN klientą mašinoje, kurioje dirbate per SSH, ir komandos viduryje sesija užšąla. Tunelis praneša, kad prisijungta, hostas pasiekia internetą per jį, o jūsų klavišų paspaudimai vis dar ateina, nors niekas negrįžta. Pasikeitė ne tunelis: tai atsakymų į jums adresuotus paketus grįžimo kelias, kuris dabar atitinka naują numatytąjį maršrutą ir patenka į tunelį, kurio nuotolinis šliuzas nenaudos pasiekti jūsų darbo stalą.
Ką iš tikrųjų įdiegia redirect-gateway
Savo def1 forma redirect-gateway prideda 0.0.0.0/1 ir 128.0.0.0/1 vietoj to, kad perrašytų numatytąjį maršrutą. Šios dvi pusės apima visą adresų erdvę, ir abi išlieka ilgesniais priešdėliais nei 0.0.0.0/0, todėl bet kokia paskirtis be konkretesnio atitikmens dabar patenka į tunelį. Tai mechanizmas, kurį verta įsiminti, nes kiekvienas toliau pateiktas pataisymas veikia įdiegdamas konkretesnį atitikmenį.
Jūsų administravimo adresas yra viena iš tų paskirčių.
VPN serveris perduoda savo klientų srautą interneto link. Jis neturi maršruto į viešą adresą, iš kurio jungiatės, ir neturi priežasties tuos paketus traktuoti kitaip nei srautą, ateinantį iš kliento, todėl juos išmeta. Tuo tarpu jūsų išsiųsta užklausa vis tiek pasiekė hostą, ir todėl sesija atrodo gyva tik iš vienos pusės.
ip route show table main | head -n 20
ip route get 198.51.100.23Raskite savo šaltinio adresą ir kelią iki tunelio
Serveryje išvardykite užmegztą SSH ryšį ir užsirašykite lygiaverčio adresą, iš kurio jis atėjo. Būtent šį adresą turi apimti jūsų grįžimo maršrutas, ir tai ne visada tas, kurį manote: šuolio hostas, NAT šliuzas ar operatoriaus vertėjas gali įstatyti kitą šaltinį.
Tada raskite fizinį šliuzą ir sąsają, kurie nešė srautą prieš tunelio paleidimą. def1 išdėstyme numatytasis maršrutas vis dar yra po pusiniais numatytaisiais, taigi informacija prieinama, nors ilgos maršrutų lentelės skaitymas akimis kviečia klaidų.
Užrašykite abi reikšmes ir sąsajos pavadinimą kartu, nes maršrutui, kurį ketinate pridėti, reikia visų trijų. Jei hostas naudojo politika pagrįstą maršrutizavimo taisyklę savo viršutinei jungčiai pasirinkti, paprastas maršrutas gali būti visai nenagrinėjamas, ir ši galimybė keičia pataisymą.
Prisekite host maršrutą, kuris pranoksta pusinius numatytuosius
Vienas /32 maršrutas yra ilgesnis nei bet kuris iš dviejų pusinių numatytųjų, todėl atsakymai į jūsų adresą renkasi jį, o ne tunelį. Kitas šuolis yra šliuzas prieš tunelį, o įrenginys yra fizinė sąsaja, kas laiko paketą tame kelyje, kurį jis naudojo prieš atsirandant tuneliui.
ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0Patikrinkite paieška, o ne žiūrėdami į lentelę: atsakymas turi įvardyti eth0 ir šliuzą, niekada tun0.
OpenVPN jau prideda host maršrutą į paties VPN serverio adresą dėl tos pačios priežasties, todėl šablonas pažįstamas, o administravimo adresas yra tiesiog dar viena išimtis. Nenaudokite route-nopull tam taisyti, nes jis išmeta stumiamus maršrutus, kurių tuneliui reikia, įskaitant nuotolinį tinklą ir DNS parinktis.
Padarykite, kad jis išgyventų prisijungimą iš naujo
Rankiniu būdu pridėtas maršrutas dingsta, kai klientas vėl prisijungia ir įdiegia savąjį, o tai pataisymą paverčia pasikartojančiu sutrikimu. Prijunkite komandą prie kažko, kas paleidžiama po maršrutų įdiegimo.
Tiek route-up scenarijus, tiek tinklo tvarkyklės pre-up kablys veikia, o patikima patikra yra prisijungimas iš naujo ir po jo ta pati paieška.
Windows atitikmuo yra nuolatinis maršrutas, pridedamas su -p, kuris išgyvena perkrovimus, bet po tinklo pakeitimo vis tiek turi rodyti į teisingą šliuzą. Kad ir kokia platforma, parašykite priežastį šalia maršruto: kitas administratorius turi žinoti, kad jis egzistuoja apsaugoti valdymo sesijai, o ne todėl, kad to reikalavo tinklo projektas.
Kai prisegtas maršrutas vis dar nepakanka
Atvirkštinio kelio filtravimas gali išmesti paketą, kuris ateina viena sąsaja ir išeina kita, ir būtent tai sukuria prisegtas maršrutas. Prieš ką nors išjungdami globaliai, patikrinkite veiksmingą rp_filter reikšmę, ir verčiau ištaisykite asimetriją, o ne išjunkite patikrą. Taikomas nustatymas pagal sąsają, o loose režimas dažnai tik registruoja asimetriją, o ne išmeta paketą. Perskaitykite abu, prieš darydami išvadą, kad filtras yra jūsų kaltė.
Hostams su politika pagrįstu maršrutizavimu reikia taisyklės, kaip ir maršruto, nes taisyklių bazė parenka lentelę anksčiau, nei nagrinėjamas joje esantis maršrutas. Maršrutas main lentelėje yra nematomas srautui, atitinkančiam taisyklę, rodančią į kitą lentelę. Perskaitykite taisykles, prieš ką nors pridėdami į main. Jei taisyklė jau apima valdymo srautą, išimtis priklauso tos taisyklės lentelei.
Bandydami laikykite atidarytą juostos išorės konsolę ir prieš atjungdami tą, kurią naudojate, dar kartą patikrinkite iš antro prisijungimo. Maršrutas, kuris jūsų pačių valdymo srautą siunčia į tunelį, nutraukia ryšį, per kurį jį taisote. Tada sugrįžti reiškia serijinę konsolę arba gelbėjimo paleidimą, o tai blogas mainas už vieno patikros žingsnio praleidimą.