Jūs per SSH prisijungiate prie kompiliavimo pagrindinio kompiuterio, paleidžiate jame VPN klientą, ir sesija nustoja atsakinėti. Niekas nesugriuvo, ir niekas neatrodo neteisingai sukonfigūruota akivaizdžia prasme. Klientas įdiegė numatytąjį maršrutą, todėl atsakymai į jūsų darbo stotį dabar išeina per tunelį, kur jūsų darbo stoties adresas nėra maršrutizuojamas. Įdomu tai, kad šis rezultatas buvo nuspėjamas, o pataisa yra vienas maršrutas, įrašomas prieš kliento paleidimą. Tarkime, serveris su viena tinklo plokšte, šliuzas 192.0.2.254 ir administratorius, prisijungiantis iš 203.0.113.9.

Užrašykite kelią prieš pradėdami

ip route show default nurodo dabartinį šliuzą ir sąsają, o ip route get 203.0.113.9 rodo, kurią sąsają ir šaltinio adresą branduolys naudotų jūsų sesijai. Išsaugokite abu išvedimus. Po tunelio pakėlimo šios dvi komandos vis tiek turėtų apibūdinti fizinį kelią, o jei jos apibūdina tunelį, sesija jau gyvena iš paskolinto laiko.

Svarbus jau užmegztas ryšys, todėl netikrinkite vien nauju prisijungimu. Nauja sesija gali trumpam pavykti per būseną, kurios senoji jau nebeturi.

Prisekite adresą pačioje kliento konfigūracijoje

Rankiniu būdu pridėtas maršrutas dingsta perkrovus ir lenktyniauja su kliento pačio lentelės atnaujinimais, todėl išimtį dėkite ten, kur lentelė valdoma. OpenVPN atveju raktinis žodis net_gateway išsprendžiamas į šliuzą, kuris egzistavo prieš tunelį, todėl route 203.0.113.9 255.255.255.255 net_gateway išlaiko tiksliai vieną adresą už jo ribų. WireGuard reikia kito požiūrio, nes wg-quick pats valdo maršrutus: nustatykite Table = off ir pridėkite išimtį PostUp, su atitinkamu PostDown, kuris ją pašalina. Abi formos išreiškia tą pačią intenciją, ir abi apriboja išimtį vienu adresu, o ne susilpnina tunelį viskam.

IPv6 atveju ta pati idėja ima vieno pagrindinio kompiuterio priešdėlį, ir įvynioto transporto atvejį verta prisiminti: jei paties tunelio išorinis ryšys gyvena fiksuotame adrese, tas adresas turi likti už tunelio, kurį jis neša, kitaip klientas maršrutizuoja savo transportą į save patį.

Arba išimkite pagrindinę lentelę iš lygties

Kai keli paslaugos pagrindiniame kompiuteryje turi išlaikyti savo įprastą kelią, nustokite redaguoti pagrindinę lentelę ir duokite klientui jo paties. Tinklo vardų erdvė su veth pora tai daro švariai: kliento numatytasis maršrutas gyvena kitame kamiene ir tunelį naudoja tik jo viduje paleisti procesai. Politinis maršrutizavimas vienai paskirties vietai pasiekia panašią vietą, siųsdamas atitinkamą srautą į skirtą lentelę, kurios numatytasis vis dar rodo į fizinį šliuzą. Bet kuris iš būdų palieka pagrindinę kompiuterio lentelę be naujo numatytojo maršruto, ir būtent ši savybė palaiko SSH atsakinėjimą.

Abu yra daugiau mechanizmų nei vienas pagrindinio kompiuterio maršrutas, ir abu verti to, kai daugiau nei vienas dalykas mašinoje turi išgyventi tunelį.

Tarkime, kad prisegimas gali nepavykti

Maršrutas, susietas su dabartiniu viešuoju adresu, nutrūksta tą akimirką, kai jūsų tiekėjas jį paskiria iš naujo. Tada nuotoliniam serveriui reikia kelio, kuris nepriklauso nuo šio adreso: konsolės, antros valdymo sąsajos arba šokinėjimo pagrindinio kompiuterio, kuris lieka už tunelio.

Dvi apsaugos priemonės kainuoja dešimt minučių. Sargas, kuris sustabdo klientą, jei per kelias minutes nepasirodo patvirtinamasis prisijungimas, užblokavimą paverčia delsimu, o antra SSH sesija, laikoma atidaryta keitimo metu, įrodo, kad išimtis veikia, kol tunelis pakeltas. Vien keepalive čia nepadeda, nes kelias dingo, o ne nenaudojamas; jie tik palengvina mirtį pastebėti.

Patikrinkite ta tvarka, kuri svarbi

Prijunkite tunelį, patvirtinkite, kad maršrutas į jūsų adresą vis dar išeina per fizinį šliuzą, tada atidarykite naują sesiją. Jei nauja sesija veikia, o senoji vis tiek miršta, priežastis yra ryšių sekimas arba būsenos ugniasienė, o ne maršrutizavimas, ir tai kita pataisa.

Įrašykite prisegtą adresą ir komandą, kuri tai įrodė, į pakeitimų žurnalą. Kitam žmogui, kuris tame kompiuteryje paleis klientą, prireiks abiejų, o adresas iki tol galėjo pasikeisti.

Susiję straipsniai