PPP-eweadres teenoor VPN-eindpunt: wat hoort in via

Een reël op 'n PPP-koppelvlak beslis die meeste van die routeringsargument op 'n VPN-boks: die binne-adres en die peer wat daarnaas gedruk word. Lees daardie paar as 'n klein subnet en jy sal soek na 'n gateway wat nie bestaan nie. Lees dit as die twee punte van 'n enkele skakel en die volgende sprong word vanself duidelik. Die vergelyking hier is tussen daardie twee lesings, want elke tabel wat jy daarna bou, erf die een wat jy gekies het. Niks omtrent die buitenste VPN-eindpunt word deur een van hulle beslis nie.

Twee lesings van een koppelvlak-reël

Neem 'n sessie waar die koppelvlak inet 10.64.3.9 peer 10.64.3.1/32 rapporteer. Die subnetlesing behandel 10.64.3.9 as 'n alleenstaande gasheer op 'n /32-eiland en soek dan 'n router om iets anderkant dit te bereik. Aangesien die enigste ander adres op die lyn die peer is, eindig daardie lesing deur 10.64.3.9 self as die gateway voor te stel, wat sirkelredenasie is.

Die eindpuntlesing is die gedokumenteerde een. Op 'n punt-tot-punt-koppelvlak benoem peer die verre punt van daardie een skakel, dus 10.64.3.1 is die bruikbare volgende sprong en 10.64.3.9 is altyd net 'n bronadres.

Daardie verskil beheer wat in via mag verskyn. Om die plaaslike adres daar te skryf, lewer 'n roete wat die kern nie na 'n buur kan oplos nie, so die inskrywing misluk in die validering of sluk verkeer terwyl dit in 'n lys heeltemal gesond lyk. Die peer werk omdat dit 'n werklike bestemming op die skakel is. Beide lesings stem saam oor die buitenste VPN-eindpunt, wat 'n heeltemal aparte identiteit is: dit word deur die onderlaag bereik, nie deur die tonnel wat dit beëindig nie.

Wat die sessie reeds geïnstalleer het

Voordat jy enige tabel van jou eie skryf, druk uit wat saam met die skakel gekom het. 'n Ondersteunde PPP-integrasie installeer gewoonlik 'n toestelroete en 'n peer-roete tydens sessie-opstelling, en daardie twee inskrywings kodeer reeds die korrekte lesing.

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

'n Toestelroete soos 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 dra geen gateway nie, want die koppelvlak self is die pad. 'n Roete wat die peer met via benoem, is 'n ander objek met 'n ander lewensduur, en dit verdwyn wanneer die sessie wegval. Om een van die twee vorms in 'n blywende tabel te kopieer sonder om te kontroleer hoe dit herinstalleer word, is die gewone rede waarom 'n werkende tonnel ná 'n herverbinding sy roete kwyt is.

Vergelyk die twee lyste eerder as om die geheue te vertrou. As die peer-roete in main bestaan maar jou ekstra tabel leeg is, het jy iets geleer wat die adresreël nooit vir jou gesê het nie.

'n Reël en 'n tabel is aparte besluite

Om 'n tabel te kies en om dit te vul is onafhanklike stappe, en die vergelyking maak hier saak omdat die twee dikwels tydens ontfouting verwar word. 'n Reël wat gemerkte verkeer na tabel 100 stuur, doen niks as tabel 100 geen passende roete het nie, en 'n goed gevulde tabel is onbereikbaar as geen reël daarheen wys nie.

Die helfte van 'n verstekroete is nie 'n verstekroete nie. 'n Enkele 0.0.0.0/1 dek die onderste helfte van die IPv4-ruimte, dus 'n beleid wat alles wil vang, het ook die passende 128.0.0.0/1 nodig, of 'n egte default. Om 'n werkende konfigurasie te lees en een van die twee helftes te kopieer, is hoe mense 'n routeringslus kry wat net by sekere bestemmings breek.

Los doelbewuste uitsonderings vir die adresse wat op die LAN moet bly, en besluit wat gebeur wanneer die opsoek niks in die gekose tabel vind nie. 'n Eksplisiete terugvalroete is makliker om oor te redeneer as 'n leë tabel, wat 'n onbereikbare resultaat teruggee en die toepassing eerder stukkend as verkeerd gerouteer laat lyk.

Vra die opsoek die vraag wat jou toepassing vra

ip route get los 'n pad op; ip route show lys gestoorde inskrywings, en die twee kan verskil sonder dat een verkeerd is. Sluit die bronkonteks in, want brongebaseerde reëls pas net wanneer die opsoek 'n bron dra.

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

Die eerste opdrag vra die vraag vanaf die gasheer. Die tweede voeg 'n inkomende koppelvlak by, wat nader is aan wat deurgevoerde verkeer ervaar, en die antwoord wys dikwels na 'n ander tabel. Nie een van die bestemmings is 'n lewendige toetsdiens nie; 198.51.100.23 is 'n dokumentasie-adres, so vervang dit met 'n gasheer wat jy mag ondersoek.

Selfs 'n korrekte opsoek bewys net dat 'n pad gekies is. Dit sê niks oor of die ander kant die verkeer aanvaar of of die antwoord deur dieselfde redenasie kan terugkeer nie.

Waar die vergelyking omkeer

Gasheerverkeer en deurgevoerde verkeer neem nie net verskillende opsoeke nie; hulle ontmoet verskillende filters op die terugpad. Linux pas omgekeerde-pad-validering toe met die strenger van die instellings vir alle koppelvlakke en vir die ontvangende koppelvlak, so 'n verandering aan een koppelvlak se waarde het miskien geen sigbare effek nie. Merkgebaseerde routering voeg die verhouding src_valid_mark by, waar die merk moet ooreenstem vir 'n bron om as geldig te geld.

As antwoorde verdwyn terwyl die uitgaande routering reg lyk, lees die effektiewe waardes voordat jy daaraan raak, en verander hulle net met 'n genoemde beleidsrede.

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

Kies tussen die twee ontwerpe op bewyse: as die toepassing aan die PPP-adres bind, is 'n bronreël plus 'n tabel met die peer-roete genoeg. As die boks vir 'n LAN daarachter deurvoer, het jy ook nodig dat die inkomende konteks en die terugpad ooreenstem. Wanneer hulle verskil, regstel die eienaarskap van die roete eerder as om die validering vir die hele masjien te verslap.