PPP peer-cím vagy VPN-végpont: melyik kerül a via alá

Egyetlen sor a PPP-interfészen eldönti a VPN-doboz útválasztási vitájának nagy részét: a belső cím és a mellette kinyomtatott peer. Olvassa ezt a párt apró alhálóként, és olyan átjárót fog keresni, amely nem létezik. Olvassa a kapcsolat két végeként, és a következő ugrás nyilvánvalóvá válik. Az összehasonlítás itt e két olvasat között van, mert minden később épített tábla az általa választottat örökli. A külső VPN-végpontról egyik sem dönt semmit.

Egy interfész-sor két olvasata

Vegyen egy munkamenetet, amelyben az interfész inet 10.64.3.9 peer 10.64.3.1/32 értéket jelent. Az alhálóként való olvasás 10.64.3.9-et magányos gazdaként kezeli egy /32-es szigeten, majd routert keres, hogy elérjen valamit azon túl. Mivel a kapcsolat egyetlen másik címe a peer, ez az olvasás végül magát 10.64.3.9-et javasolja átjáróként, ami körkörös.

A végpontként való olvasás a dokumentált. Pont-pont interfészen peer a kapcsolat távoli végét nevezi meg, tehát 10.64.3.1 a használható következő ugrás, és 10.64.3.9 mindig csak forrás-cím.

Ez a különbség határozza meg, mi állhat via alatt. A helyi cím odaírása olyan útvonalat ad, amelyet a kernel nem tud szomszédhoz rendelni, így a bejegyzés vagy elbukik az ellenőrzésen, vagy elnyeli a forgalmat, miközben egy listában teljesen egészségesnek látszik. A peer azért működik, mert valódi cél a kapcsolaton. Mindkét olvasat egyetért a külső VPN-végpontban, amely teljesen külön identitás: az underlayen keresztül érhető el, nem a tunelen keresztül, amelyet lezár.

Mit telepített már a munkamenet

Mielőtt saját táblát írna, nyomtassa ki, mi jött a kapcsolattal. Egy támogatott PPP-integráció általában eszközútvonalat és peer-útvonalat telepít a munkamenet beállításakor, és ez a két bejegyzés már a helyes olvasatot kódolja.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Egy eszközútvonal, mint 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9, nem hordoz átjárót, mert maga az interfész az út. A peer-t via-tel megnevező útvonal más objektum, más élettartammal, és eltűnik, amikor a munkamenet megszakad. A két forma valamelyikének átmásolása egy tartós táblába anélkül, hogy ellenőriznénk, hogyan telepítődik újra, a szokásos oka annak, hogy egy működő tunel újracsatlakozás után elveszíti az útvonalát.

Hasonlítsa össze a két listát, ahelyett hogy a memóriára bízná magát. Ha a peer-útvonal létezik main alatt, de a kiegészítő táblája üres, megtanult valamit, amit a cím sor soha nem mondott el.

A szabály és a tábla külön döntés

A tábla kiválasztása és feltöltése független lépések, és az összehasonlítás itt számít, mert a kettőt hibakereséskor gyakran összekeverik. Egy szabály, amely a megjelölt forgalmat a 100-as táblába küldi, semmit sem tesz, ha a 100-as táblában nincs megfelelő útvonal, és egy jól feltöltött tábla elérhetetlen, ha egyetlen szabály sem mutat rá.

Az alapértelmezett útvonal fele nem alapértelmezett útvonal. Egyetlen 0.0.0.0/1 lefedi az IPv4-tér alsó felét, ezért a mindent elkapni kívánó házirendnek a megfelelő 128.0.0.0/1-ra is szüksége van, vagy egy valódi default-ra. Egy működő konfiguráció elolvasása és a két fél valamelyikének lemásolása az, ahogy az emberek olyan útválasztási hurokba kerülnek, amely csak bizonyos céloknál törik el.

Hagyjon szándékos kivételeket azoknak a címeknek, amelyeknek a LAN-on kell maradniuk, és döntse el, mi történik, ha a keresés semmit sem talál a kiválasztott táblában. Egy kifejezett tartalék útvonal könnyebben átgondolható, mint egy üres tábla, amely elérhetetlen eredményt ad, és az alkalmazást inkább töröttnek, mint rosszul irányítottnak mutatja.

Tegye fel a keresésnek azt a kérdést, amelyet az alkalmazása feltesz

ip route get felold egy útvonalat; ip route show kilistázza a tárolt bejegyzéseket, és a kettő ellentmondhat egymásnak anélkül, hogy bármelyik hibás lenne. Vegye bele a forrás kontextusát, mert a forrásalapú szabályok csak akkor egyeznek, ha a keresés forrást hordoz.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Az első parancs a gazdától teszi fel a kérdést. A második hozzáad egy bemeneti interfészt, ami közelebb van ahhoz, amit a továbbított forgalom tapasztal, és a válasz gyakran másik táblára mutat. Egyik cél sem élő teszt-szolgáltatás; 198.51.100.23 dokumentációs cím, ezért helyettesítse olyan gazdával, amelyet szabadon vizsgálhat.

Még egy helyes keresés is csak azt bizonyítja, hogy útvonalat választottak. Semmit sem mond arról, hogy a másik fél elfogadja-e a forgalmat, vagy hogy a válasz ugyanazzal az érveléssel visszatérhet-e.

Ahol az összehasonlítás megfordul

A gazda forgalma és a továbbított forgalom nem csak különböző kereséseket végez; visszafelé különböző szűrőkkel találkozik. A Linux a fordított útvonal ellenőrzését az összes interfész és a fogadó interfész beállításai közül a szigorúbbal végzi, ezért egy interfész értékének megváltoztatása látható hatás nélkül maradhat. A jelölésalapú útválasztás hozzáadja a src_valid_mark viszonyt, amelyben a jelölésnek egyeznie kell ahhoz, hogy egy forrás érvényesnek számítson.

Ha a válaszok eltűnnek, miközben a kimenő útválasztás helyesnek látszik, olvassa ki a tényleges értékeket, mielőtt hozzájuk nyúlna, és csak megadott házirend-indokkal módosítsa őket.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

A két terv közül bizonyítékok alapján válasszon: ha az alkalmazás a PPP-címhez kötődik, elég egy forrásszabály és egy tábla a peer-útvonallal. Ha a doboz a mögötte lévő LANért továbbít, ahhoz is szükség van, hogy a bemeneti kontextus és a visszaút egyezzen. Ha nem egyeznek, javítsa az útvonal tulajdonjogát, ahelyett hogy az egész gép ellenőrzését lazítaná.