Kaip Linuxe atskirti VPN stumiamus maršrutus nuo statinių

Nešiojamajame kompiuteryje atsiranda priešdėlis, kai pakyla tunelis, todėl atrodo, kad jį įdiegė VPN. Galbūt taip ir yra, bet toks pat rezultatas gali kilti iš kliento scenarijaus, paleidžiamo jungiantis, jungties profilio, kuriame išvardytas potinklis, arba statinio maršruto, kuris buvo visą laiką ir pradėjo veikti tik tada, kai sąsaja atsirado. Pasirinkus neteisingą šaltinį, maršrutas grįžta po kiekvieno valymo, o kitas žmogus kartoja tą pačią pataisą. Toliau pateikta seka atskiria šiuos tris, prieš ką nors keičiant.

1 žingsnis: įvardykite mechanizmą, kuris įdiegia priešdėlius

Skirtingi protokolai pasiekiamumą užtikrina skirtingais būdais, o viso to vadinimas skelbimu paslepia skirtumą. OpenVPN serveris stumia maršruto direktyvą valdymo kanalu, o klientas ją įdiegia, nebent pull filtras ją blokuoja. WireGuard konfigūracija vietoje išvardija leidžiamus priešdėlius, kuriuos klientas naudoja ir šifravimo raktų maršrutizavimui, ir pridedamiems maršrutams. IPsec tunelis su partneriu suderina srauto selektorius, o branduolys iš tų selektorių įdiegia maršrutus.

Prieš skaitydami bet kokią lentelę nustatykite, kurį iš jų naudoja jūsų tunelis. Jungiantis stumiamas maršrutas nėra maršrutizavimo protokolo skelbimas ir nežada, kad priešdėlis pasiekiamas už tolimojo galo. Užsirašykite mechanizmą prie priešdėlio, nes jis nusprendžia, kur priklauso pataisa.

2 žingsnis: palyginkite lentelę per vieną jungtį

Išsaugokite pagrindinę lentelę tuneliui esant nuleistam, pakelkite jį, išsaugokite dar kartą ir palyginkite du įrašus. Viskas, kas atsirado, priklauso jungties gyvavimo ciklui, o viskas, kas liko, priklauso vietinei konfigūracijai.

Užfiksuokite ją su ip route show table main > /tmp/route-down.txt, prisijunkite ir užfiksuokite dar kartą. Tą patį padarykite su ip -6 route, jei svetainė naudoja IPv6, nes ten trūkstamas priešdėlis sukelia gedimus, kurie atrodo nesusiję su maršrutizavimu.

3 žingsnis: skaitykite metriką, ne tik buvimą

Dvi įrašai tam pačiam priešdėliui gali egzistuoti kartu, o branduolys pasirenka mažesnę metriką. Statinis maršrutas su metrika 50 ir toliau nugalės stumiamą maršrutą su 100, nors abu matomi, todėl „maršrutas yra“ ir „srautas jį naudoja“ yra skirtingi teiginiai.

Paklauskite branduolio tiesiogiai su ip route get 10.20.5.7 ir perskaitykite sąsają, kurią jis nurodo. Jei srautas išeina per fizinį adapterį, o lentelėje yra tunelio maršrutas, tai paaiškina metrika arba priešdėlio ilgis, o ne VPN klientas. Pakartokite paiešką su vedėju, apie kurį žinote, kad jis yra už tunelio, ir su tokiu, apie kurį žinote, kad ne, ir skirtumas parodys, ar skaidymas elgiasi kaip numatyta.

4 žingsnis: raskite įrašus, kurie pergyvena tunelį

Statiniai maršrutai pagal projektą pergyvena atjungimą, ir iš ten atsiranda pasenę įrašai. Nuolatinis maršrutas į sąsają, kurios nebėra, gali tyliai praryti potinklį, o maršrutas į pakartotinai naudojamą sąsajos pavadinimą po perkrovimo gali išleisti privatų srautą pro netinkamas duris.

Patikrinkite nuolatinę pusę toje vietoje, kurią naudoja jūsų distribucija: ar tai systemd-networkd įrenginys, NetworkManager profilis, ar scenarijus kliento up kataloge. Gyvos lentelės taisymas su ip route del laikosi tik iki kito prisijungimo. Šį trynimą laikykite hipotezės patikrinimu, o ne remontu.

Kai tolimasis galas pateikia neteisingą aprėptį, kelkite tai operatoriui, o ne filtruokite viską. Visų stumiamų nustatymų atsisakymas taip pat atmeta DNS ir padalyto tunelio politiką, nuo kurių priklauso profilis.

5 žingsnis: patvirtinkite grįžimo kelią, prieš kaltindami klientą

Svetainės su svetaine jungčiai arba potinkliui už tunelio tolimajai pusei reikia maršruto atgal į jūsų kliento adresą ir įjungto persiuntimo šliuze. Vienos krypties kelias atrodo lygiai kaip kliento maršrutizavimo klaida, tik rankos paspaudimas ir išeinantis paketas abu pavyksta.

Atvirkštinio kelio filtravimas prideda antrą spąstą Linux šliuzuose. Atsakymas, atėjęs kita sąsaja nei numato maršrutas, griežtu režimu atmetamas, o asimetriniai keliai per du tiekėjus tai patikimai sukelia. Atmetimų skaitikliai šliuze, o ne kliente, pasako, ar filtravimas yra priežastis.

6 žingsnis: testuokite išteklių, o ne ping

Kai pasirinktas maršrutas teisingas, atidarykite tikrąjį išteklį ir patvirtinkite grįžtantį srautą. Ping atsakymas įrodo kelią viena kryptimi ir nieko apie paslaugą, o paslauga, atsakanti į podėlyje esančią jungtį, įrodo dar mažiau.

Tada pakartokite visą patikrinimą po pakartotinio prisijungimo. Sekos vertė ta, kad ji numato, ką darys kitas prisijungimas, todėl ir palyginimas, ir metrika priklauso bilietui.