Hoe om deur VPN gestuurde roetes van statiese roetes op Linux te onderskei

’n Prefiks verskyn op die skootrekenaar wanneer die tonnel opkom, so dit voel of die VPN dit geïnstalleer het. Dit het miskien, maar dieselfde resultaat kan kom van ’n kliëntskrip wat by verbinding loop, ’n verbindingsprofiel wat die subnet lys, of ’n statiese roete wat die hele tyd daar was en eers begin werk het toe die koppelvlak bestaan het. Om die verkeerde eienaar te kies beteken die roete kom ná elke opruiming terug, en die volgende persoon herhaal dieselfde oplossing. Die volgorde hieronder skei die drie voordat enigiets verander word.

Stap 1: noem die meganisme wat prefikse installeer

Verskillende protokolle voorsien bereikbaarheid op verskillende maniere, en om dit alles ’n aankondiging te noem verberg die onderskeid. ’n OpenVPN-bediener stuur ’n roetedirektief oor die beheerkanaal en die kliënt installeer dit tensy ’n pull-filter dit blokkeer. ’n WireGuard-konfigurasie lys toegelate prefikse plaaslik, wat die kliënt vir beide kriptosleutelroetering en vir die roetes wat dit byvoeg gebruik. ’n IPsec-tonnel stem verkeerskeurders met die eweknie af, en die kernel installeer roetes uit daardie keurders.

Identifiseer watter van dié jou tonnel gebruik voordat jy enige tabel lees. ’n Roete wat by verbindingstyd gestuur word, is nie ’n aankondiging van ’n roeteringsprotokol nie, en dit belowe niks dat die prefiks agter die verre kant bereikbaar is nie. Let op die meganisme langs die prefiks, want dit bepaal waar die oplossing hoort.

Stap 2: vergelyk die tabel oor ’n verbinding

Stoor die hooftabel terwyl die tonnel af is, bring dit op, stoor dit weer en vergelyk die twee opnames. Enigiets wat verskyn het, hoort by die verbindingslewensiklus, en enigiets wat gebly het, hoort by plaaslike konfigurasie.

Maak ’n opname met ip route show table main > /tmp/route-down.txt, verbind en maak weer ’n opname. Doen dieselfde vir ip -6 route as die werf IPv6 gebruik, want ’n ontbrekende prefiks daar veroorsaak foute wat na niks met roetering te doen het nie.

Stap 3: lees die metriek, nie net die teenwoordigheid nie

Twee inskrywings vir dieselfde prefiks kan saambestaan, en die kernel kies die laer metriek. ’n Statiese roete met metriek 50 bly wen teenoor ’n gestuurde roete op 100, selfs al is albei sigbaar, en daarom is ‘die roete is daar’ en ‘verkeer gebruik dit’ twee verskillende stellings.

Vra die kernel direk met ip route get 10.20.5.7 en lees die koppelvlak wat dit rapporteer. As verkeer deur die fisiese adapter vertrek terwyl ’n tonnelroete in die tabel sit, verduidelik die metriek of die prefikslengte dit, nie die VPN-kliënt nie. Herhaal die soektog vir ’n gasheer waarvan jy weet dit leef agter die tonnel en vir een waarvan jy weet dit doen nie, en die verskil wys of die splitsing werk soos bedoel.

Stap 4: vind die inskrywings wat die tonnel oorleef

Statiese roetes oorleef ’n ontkoppeling volgens ontwerp, en dit is waar verouderde inskrywings vandaan kom. ’n Aanhoudende roete wat na ’n koppelvlak wys wat nie meer bestaan nie, kan ’n subnet stilweg in ’n swartgat laat beland, en een wat na ’n hergebruikte koppelvlaknaam wys, kan private verkeer ná ’n herlaai uit die verkeerde deur stuur.

Kyk na die aanhoudende kant op die plek wat jou verspreiding gebruik, of dit ’n systemd-networkd-eenheid, ’n NetworkManager-profiel of ’n skrip in die kliënt se up-gids is. Om die lewende tabel met ip route del reg te maak, hou net tot die volgende verbinding. Behandel daardie skrapping as ’n toets van die hipotese eerder as die herstel.

Waar die verre kant die verkeerde dekking lewer, lig dit by die operateur aan eerder as om alles te filter. Om alle gestuurde instellings te laat val, gooi ook DNS en splits-tonnelbeleid weg waarvan die profiel afhanklik is.

Stap 5: bevestig die terugpad voordat jy die kliënt blameer

Vir ’n werf-tot-werf of ’n subnet agter die tonnel het die verre kant ’n roete terug na jou kliëntadres nodig en moet doorstuur op die poort aan wees. ’n Eenrigtingpad lyk presies soos ’n kliëntroeteringsfout, behalwe dat die handdruk en die uitgaande pakket albei slaag.

Omgekeerde-pad-filtering voeg ’n tweede lokval op Linux-poorte by. ’n Antwoord wat op ’n ander koppelvlak aankom as wat die roete voorspel, word deur streng modus laat val, en asimmetriese paaie deur twee verskaffers veroorsaak dit betroubaar. Die val-tellers op die poort, nie op die kliënt nie, sê of filtering die oorsaak is.

Stap 6: toets die hulpbron, nie die ping nie

Sodra die gekose roete reg is, maak die werklike hulpbron oop en bevestig die terugverkeer. ’n Ping-antwoord bewys die pad in een rigting en niks oor die diens nie, en ’n diens wat op ’n gekaste verbinding antwoord, bewys selfs minder.

Herhaal dan die hele kontrole ná ’n herverbinding. Die waarde van die volgorde is dat dit voorspel wat die volgende verbinding gaan doen, en daarom hoort beide die vergelyking en die metriek in die kaartjie.