Kako razlikovati rute koje gura VPN od statičkih ruta na Linuxu

Prefiks se pojavi na laptopu kada se tunel podigne, pa se čini da ga je VPN instalirao. Možda jeste, ali isti rezultat može doći od klijentske skripte koja se pokreće pri povezivanju, profila veze koji navodi podmrežu ili statičke rute koja je bila tu cijelo vrijeme i počela raditi tek kada je interfejs postojao. Pogrešan vlasnik znači da se ruta vraća nakon svakog čišćenja, a sljedeća osoba ponavlja istu popravku. Slijed ispod razdvaja ta tri prije nego što se bilo šta promijeni.

Korak 1: imenujte mehanizam koji instalira prefikse

Različiti protokoli obezbjeđuju dostupnost na različite načine, a nazivati sve to najavom skriva razliku. OpenVPN server gura direktivu rute preko kontrolnog kanala i klijent je instalira osim ako je pull filter blokira. WireGuard konfiguracija lokalno navodi dozvoljene prefikse, koje klijent koristi i za kriptoključno rutiranje i za rute koje dodaje. IPsec tunel usaglašava selektore saobraćaja sa partnerom, a kernel instalira rute iz tih selektora.

Utvrdite koji od njih koristi vaš tunel prije nego što pročitate bilo koju tabelu. Ruta gurnuta u trenutku povezivanja nije najava protokola rutiranja i ne obećava da je prefiks dostupan iza udaljenog kraja. Zabilježite mehanizam uz prefiks, jer on odlučuje gdje popravka pripada.

Korak 2: uporedite tabelu kroz jedno povezivanje

Sačuvajte glavnu tabelu dok je tunel spušten, podignite ga, sačuvajte ponovo i uporedite dva snimka. Sve što se pojavilo pripada životnom ciklusu veze, a sve što je ostalo pripada lokalnoj konfiguraciji.

Snimite je pomoću ip route show table main > /tmp/route-down.txt, povežite se i snimite ponovo. Uradite isto za ip -6 route ako stranica koristi IPv6, jer prefiks koji tamo nedostaje stvara kvarove koji izgledaju nepovezani s rutiranjem.

Korak 3: čitajte metriku, ne samo prisustvo

Dva unosa za isti prefiks mogu postojati zajedno, a kernel bira nižu metriku. Statička ruta s metrikom 50 nastaviće pobjeđivati gurnutu rutu na 100 iako su obje vidljive, zato su „ruta je tu“ i „saobraćaj je koristi“ različite tvrdnje.

Pitajte kernel direktno pomoću ip route get 10.20.5.7 i pročitajte interfejs koji prijavi. Ako saobraćaj izlazi kroz fizički adapter dok ruta tunela stoji u tabeli, to objašnjava metrika ili dužina prefiksa, a ne VPN klijent. Ponovite provjeru za host za koji znate da je iza tunela i za onaj za koji znate da nije, a razlika pokazuje da li podjela radi kako je predviđeno.

Korak 4: pronađite unose koji nadživljavaju tunel

Statičke rute preživljavaju prekid veze po dizajnu i odatle dolaze zastarjeli unosi. Trajna ruta koja pokazuje na interfejs koji više ne postoji može tiho progutati podmrežu, a ona koja pokazuje na ponovo iskorišteno ime interfejsa može poslije ponovnog pokretanja poslati privatni saobraćaj kroz pogrešna vrata.

Provjerite trajnu stranu na mjestu koje koristi vaša distribucija, bilo da je to systemd-networkd jedinica, NetworkManager profil ili skripta u klijentovom up direktoriju. Popravka žive tabele pomoću ip route del drži samo do sljedećeg povezivanja. Tretirajte to brisanje kao test hipoteze, a ne kao popravku.

Kada udaljeni kraj daje pogrešnu pokrivenost, obratite se operateru umjesto da filtrirate sve. Odbacivanje svih gurnutih postavki odbacuje i DNS i politiku podijeljenog tunela na kojima profil zavisi.

Korak 5: potvrdite povratni put prije nego okrivite klijent

Za vezu lokacija-lokacija ili podmrežu iza tunela, udaljenoj strani treba ruta nazad do adrese vašeg klijenta i omogućeno prosljeđivanje na gatewayu. Jednosmjerni put izgleda tačno kao bug u rutiranju klijenta, osim što rukovanje i odlazni paket oboje uspijevaju.

Filtriranje obrnutog puta dodaje drugu zamku na Linux gatewayima. Odgovor koji stigne na drugi interfejs od onog koji ruta predviđa biva odbačen strogim režimom, a asimetrični putevi kroz dva provajdera to pouzdano pokreću. Brojači odbacivanja na gatewayu, a ne na klijentu, kažu da li je filtriranje uzrok.

Korak 6: testirajte resurs, ne ping

Kada je odabrana ruta ispravna, otvorite stvarni resurs i potvrdite povratni saobraćaj. Odgovor na ping dokazuje put u jednom smjeru i ništa o usluzi, a usluga koja odgovara na keširanu vezu dokazuje još manje.

Zatim ponovite cijelu provjeru nakon ponovnog povezivanja. Vrijednost slijeda je u tome što predviđa šta će sljedeće povezivanje uraditi, zato i poređenje i metrika pripadaju u tiket.