Kā Linux atšķirt VPN virzītos maršrutus no statiskajiem

Portatīvajā datorā parādās prefikss, kad tunelis paceļas, tāpēc šķiet, ka to uzstādījis VPN. Varbūt arī uzstādīja, bet tādu pašu rezultātu var dot klienta skripts, kas darbojas savienošanās laikā, savienojuma profils, kurā uzskaitīts apakštīkls, vai statisks maršruts, kas bija visu laiku un sāka darboties tikai tad, kad saskarne pastāvēja. Nepareiza avota izvēle nozīmē, ka maršruts atgriežas pēc katras tīrīšanas, un nākamā persona atkārto to pašu labojumu. Tālākā secība atdala šos trīs, pirms kaut kas tiek mainīts.

1. solis: nosauciet mehānismu, kas uzstāda prefiksus

Dažādi protokoli nodrošina sasniedzamību dažādos veidos, un visa tā saukšana par paziņojumu slēpj atšķirību. OpenVPN serveris virza maršruta direktīvu pa vadības kanālu, un klients to uzstāda, ja vien pull filtrs to nebloķē. WireGuard konfigurācija lokāli uzskaita atļautos prefiksus, ko klients izmanto gan šifrēšanas atslēgu maršrutēšanai, gan maršrutiem, ko tas pievieno. IPsec tunelis ar partneri vienojas par trafika selektoriem, un kodols uzstāda maršrutus no šiem selektoriem.

Pirms lasīt jebkuru tabulu, nosakiet, kuru no tiem izmanto jūsu tunelis. Savienošanās laikā virzīts maršruts nav maršrutēšanas protokola paziņojums un nesola, ka prefikss ir sasniedzams aiz tālā gala. Pierakstiet mehānismu blakus prefiksam, jo tas nosaka, kur labojums pieder.

2. solis: salīdziniet tabulu vienas savienošanās gaitā

Saglabājiet galveno tabulu ar nolaistu tuneli, paceliet to, saglabājiet vēlreiz un salīdziniet abus ierakstus. Viss, kas parādījās, pieder savienojuma dzīves ciklam, un viss, kas palika, pieder vietējai konfigurācijai.

Ierakstiet to ar ip route show table main > /tmp/route-down.txt, savienojieties un ierakstiet vēlreiz. Dariet to pašu ar ip -6 route, ja vietne izmanto IPv6, jo tur trūkstošs prefikss rada kļūmes, kas izskatās nesaistītas ar maršrutēšanu.

3. solis: lasiet metriku, ne tikai esamību

Divi ieraksti vienam prefiksam var pastāvēt līdzās, un kodols izvēlas zemāko metriku. Statisks maršruts ar metriku 50 turpinās uzvarēt virzīto maršrutu ar 100, lai gan abi ir redzami, tāpēc „maršruts ir tur“ un „trafiks to izmanto“ ir dažādi apgalvojumi.

Pajautājiet kodolam tieši ar ip route get 10.20.5.7 un izlasiet saskarni, ko tas norāda. Ja trafiks iziet caur fizisko adapteri, kamēr tabulā sēž tuneļa maršruts, to izskaidro metrika vai prefiksa garums, nevis VPN klients. Atkārtojiet meklēšanu resursdatoram, par kuru zināt, ka tas ir aiz tuneļa, un tādam, par kuru zināt, ka nav, un atšķirība parādīs, vai sadalījums darbojas kā paredzēts.

4. solis: atrodiet ierakstus, kas pārdzīvo tuneli

Statiskie maršruti pēc konstrukcijas pārdzīvo atvienošanos, un tieši no turienes nāk novecojuši ieraksti. Pastāvīgs maršruts uz saskarni, kas vairs neeksistē, var klusi aprīt apakštīklu, un maršruts uz atkārtoti izmantotu saskarnes nosaukumu pēc pārstartēšanas var izlaist privātu trafiku pa nepareizajām durvīm.

Pārbaudiet pastāvīgo pusi vietā, ko izmanto jūsu distribūcija: vai tā ir systemd-networkd vienība, NetworkManager profils vai skripts klienta up mapē. Dzīvās tabulas labošana ar ip route del noturas tikai līdz nākamajai savienošanās reizei. Uzskatiet šo dzēšanu par hipotēzes pārbaudi, nevis remontu.

Kur tālais gals sniedz nepareizu pārklājumu, celiet to operatoram, nevis filtrējiet visu. Visu virzīto iestatījumu izmešana izmet arī DNS un sadalītā tuneļa politiku, no kuras profils ir atkarīgs.

5. solis: apstipriniet atgriešanās ceļu, pirms vainojat klientu

Vietnes uz vietni savienojumam vai apakštīklam aiz tuneļa tālajai pusei vajag maršrutu atpakaļ uz jūsu klienta adresi un ieslēgtu pāradresāciju vārtejā. Vienvirziena ceļš izskatās tieši kā klienta maršrutēšanas kļūda, tikai rokas paspiešana un izejošā pakete abas izdodas.

Atgriešanās ceļa filtrēšana Linux vārtejām pievieno otru slazdu. Atbilde, kas ierodas citā saskarnē, nekā maršruts paredz, tiek izmesta stingrajā režīmā, un asimetriski ceļi caur diviem pakalpojumu sniedzējiem to droši izraisa. Atmešanas skaitītāji vārtejā, nevis klientā, pasaka, vai filtrēšana ir cēlonis.

6. solis: pārbaudiet resursu, nevis ping

Kad izvēlētais maršruts ir pareizs, atveriet īsto resursu un apstipriniet atgriešanās trafiku. Ping atbilde pierāda ceļu vienā virzienā un neko par pakalpojumu, un pakalpojums, kas atbild uz kešatmiņā saglabātu savienojumu, pierāda vēl mazāk.

Pēc tam atkārtojiet visu pārbaudi pēc atkārtotas savienošanās. Secības vērtība ir tajā, ka tā paredz, ko darīs nākamā savienošanās, tāpēc gan salīdzinājums, gan metrika pieder biļetei.