PPP-peeradres versus VPN-eindpunt: wat hoort er in via

Eén regel op een PPP-interface beslecht het grootste deel van de routingdiscussie op een VPN-box: het binnenadres en de peer die ernaast wordt afgedrukt. Lees dat paar als een piepklein subnet en je gaat op zoek naar een gateway die niet bestaat. Lees het als de twee uiteinden van één verbinding en de next hop wordt vanzelf duidelijk. De vergelijking hier gaat tussen die twee lezingen, want elke tabel die je daarna bouwt, erft degene die je hebt gekozen. Over het buitenste VPN-eindpunt beslist geen van beide iets.

Twee lezingen van één interfaceregel

Neem een sessie waarin de interface inet 10.64.3.9 peer 10.64.3.1/32 meldt. De subnetlezing behandelt 10.64.3.9 als een losse host op een /32-eiland en zoekt vervolgens een router om iets buiten dat eiland te bereiken. Omdat het enige andere adres op de lijn de peer is, stelt die lezing uiteindelijk 10.64.3.9 zelf als gateway voor, wat cirkelredenering is.

De eindpuntlezing is de gedocumenteerde. Op een point-to-point-interface benoemt peer het verre uiteinde van die ene verbinding, dus 10.64.3.1 is de bruikbare next hop en 10.64.3.9 is altijd alleen een bronadres.

Dat verschil bepaalt wat er in via mag staan. Het lokale adres daar neerzetten levert een route op die de kernel niet aan een buur kan koppelen, dus de vermelding faalt bij de validatie of slikt verkeer in terwijl ze er in een lijst volkomen gezond uitziet. De peer werkt omdat hij een echte bestemming op de verbinding is. Beide lezingen zijn het eens over het buitenste VPN-eindpunt, dat een volledig aparte identiteit is: het wordt bereikt via de underlay, niet via de tunnel die het beëindigt.

Wat de sessie al heeft geïnstalleerd

Voordat je een eigen tabel schrijft, druk je af wat er met de verbinding is meegekomen. Een ondersteunde PPP-integratie installeert tijdens het opzetten van de sessie meestal een apparaatroute en een peerroute, en die twee vermeldingen coderen al de juiste lezing.

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

Een apparaatroute zoals 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 draagt geen gateway, omdat de interface zelf het pad is. Een route die de peer met via benoemt, is een ander object met een andere levensduur, en hij verdwijnt wanneer de sessie wegvalt. Een van beide vormen in een persistente tabel kopiëren zonder te controleren hoe hij opnieuw wordt geïnstalleerd, is de gebruikelijke reden waarom een werkende tunnel na een herverbinding zijn route kwijt is.

Vergelijk de twee lijsten in plaats van op je geheugen te vertrouwen. Als de peerroute in main bestaat maar je extra tabel leeg is, heb je iets geleerd wat de adresregel je nooit heeft verteld.

Een regel en een tabel zijn aparte beslissingen

Een tabel kiezen en hem vullen zijn onafhankelijke stappen, en de vergelijking is hier van belang omdat beide bij het debuggen vaak worden verward. Een regel die gemarkeerd verkeer naar tabel 100 stuurt, doet niets als tabel 100 geen passende route heeft, en een goed gevulde tabel is onbereikbaar als geen regel ernaar wijst.

De helft van een defaultroute is geen defaultroute. Een enkele 0.0.0.0/1 dekt de onderste helft van de IPv4-ruimte, dus een policy die alles wil vangen heeft ook de bijpassende 128.0.0.0/1 nodig, of een echte default. Een werkende configuratie lezen en een van de twee helften kopiëren is hoe mensen een routingloop krijgen die alleen bij bepaalde bestemmingen breekt.

Laat bewuste uitzonderingen staan voor adressen die op het LAN moeten blijven, en beslis wat er gebeurt als de opzoeking in de gekozen tabel niets vindt. Een expliciete fallbackroute is makkelijker te beredeneren dan een lege tabel, die een unreachable-resultaat teruggeeft en de toepassing eerder kapot dan verkeerd gerouteerd laat lijken.

Stel de opzoeking de vraag die je toepassing stelt

ip route get lost een pad op; ip route show toont opgeslagen vermeldingen, en de twee kunnen het oneens zijn zonder dat een van beide fout is. Neem de broncontext mee, want op de bron gebaseerde regels matchen alleen als de opzoeking een bron meedraagt.

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

De eerste opdracht stelt de vraag vanuit de host. De tweede voegt een inkomende interface toe, wat dichter bij wat doorgestuurd verkeer meemaakt ligt, en het antwoord wijst vaak naar een andere tabel. Geen van beide bestemmingen is een live testdienst; 198.51.100.23 is een documentatieadres, dus vervang het door een host die je mag aftasten.

Zelfs een correcte opzoeking bewijst alleen dat er een pad is gekozen. Ze zegt niets over de vraag of de andere kant het verkeer aanvaardt of de reactie via dezelfde redenering kan terugkeren.

Waar de vergelijking kantelt

Hostverkeer en doorgestuurd verkeer nemen niet alleen andere opzoekingen; ze treffen op de terugweg ook andere filters. Linux past reverse-path-validatie toe met de strengste van de instellingen voor alle interfaces en voor de ontvangende interface, dus het wijzigen van de waarde van één interface heeft mogelijk geen zichtbaar effect. Op marks gebaseerde routing voegt de relatie src_valid_mark toe, waarbij de mark moet kloppen wil een bron als geldig gelden.

Als reacties verdwijnen terwijl de uitgaande routing er goed uitziet, lees je de effectieve waarden voordat je ze aanraakt, en wijzig je ze alleen met een genoemd policy-doel.

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

Kies tussen de twee ontwerpen op basis van bewijs: als de toepassing aan het PPP-adres bindt, volstaan een bronregel plus een tabel met de peerroute. Als de box voor een LAN erachter doorstuurt, moeten ook de inkomende context en het terugpad het eens zijn. Als ze het oneens zijn, herstel je het eigenaarschap van de route in plaats van de validatie voor de hele machine te versoepelen.