PPP peer-aadress või VPN lõpp-punkt: kumb läheb via-sse

Üks rida PPP-liidesel lahendab suurema osa VPN-karbi marsruutimisvaidlusest: sisemine aadress ja selle kõrvale trükitud peer. Lugege seda paari tillukese alavõrguna ja te otsite lüüsi, mida ei ole olemas. Lugege seda ühe lüli kahe otsana ja järgmine hüpe muutub ilmselgeks. Võrdlus on siin nende kahe lugemise vahel, sest iga hiljem ehitatud tabel pärib selle, mille valisite. Välise VPN-lõpp-punkti kohta ei otsusta kumbki neist midagi.

Kaks lugemist ühest liidese realt

Võtke seanss, kus liides teatab inet 10.64.3.9 peer 10.64.3.1/32. Alavõrgu lugemine kohtleb 10.64.3.9 üksiku hostina /32 saarel ja otsib seejärel ruuterit, et jõuda millenigi sellest väljapoole. Kuna ainus teine aadress lülil on peer, pakub see lugemine lõpuks 10.64.3.9 ise lüüsina, mis on ringikujuline.

Lõpp-punkti lugemine on dokumenteeritu. Punkt-punkt-liidesel nimetab peer selle ühe lüli kaugemat otsa, seega 10.64.3.1 on kasutatav järgmine hüpe ja 10.64.3.9 on alati ainult lähteaadress.

See erinevus määrab, mis võib olla via. Kohaliku aadressi sinna kirjutamine annab marsruudi, mida tuum ei suuda naabriga siduda, seega kirje kas läbib valideerimise või neelab liikluse, näides samal ajal loendis täiesti tervena. Peer töötab, sest see on tõeline sihtkoht lülil. Mõlemad lugemised nõustuvad välise VPN-lõpp-punkti osas, mis on täiesti eraldi identiteet: sinna jõutakse underlay kaudu, mitte selle lõpetatava tunneli kaudu.

Mida seanss on juba paigaldanud

Enne oma tabeli kirjutamist printige, mis lüliga kaasa tuli. Toetatud PPP-integratsioon paigaldab seansi seadistamisel tavaliselt seadme marsruudi ja peer-marsruudi ning need kaks kirjet kodeerivad juba õige lugemise.

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

Seadme marsruut nagu 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ei kanna lüüsi, sest liides ise on tee. Marsruut, mis nimetab peeri via abil, on teine objekt teise elueaga ja see kaob, kui seanss katkeb. Ühe kahest vormist kopeerimine püsivasse tabelisse ilma kontrollimata, kuidas see uuesti paigaldatakse, on tavaline põhjus, miks töötav tunnel kaotab pärast taasühendamist oma marsruudi.

Võrrelge kahte loendit, selle asemel et mälule lootma jääda. Kui peer-marsruut on olemas main, kuid teie lisatabel on tühi, õppisite midagi, mida aadressirida teile kunagi ei öelnud.

Reegel ja tabel on eraldi otsused

Tabeli valimine ja selle täitmine on sõltumatud sammud ning võrdlus loeb siin, sest silumisel aetakse neid kahte sageli segi. Reegel, mis saadab märgitud liikluse tabelisse 100, ei tee midagi, kui tabelis 100 pole sobivat marsruuti, ja hästi täidetud tabel on kättesaamatu, kui ükski reegel sellele ei osuta.

Pool vaikemarsruuti ei ole vaikemarsruut. Üks 0.0.0.0/1 katab IPv4-ruumi alumise poole, seega poliitika, mis kavatseb kõik kinni püüda, vajab ka vastavat 128.0.0.0/1 või tõelist default. Töötava konfiguratsiooni lugemine ja ühe kahest pooleest kopeerimine on viis, kuidas inimesed jõuavad marsruutimistsüklisse, mis katkeb ainult teatud sihtkohtadel.

Jätke tahtlikud erandid aadressidele, mis peavad jääma LAN-i, ja otsustage, mis juhtub, kui otsing valitud tabelist midagi ei leia. Selgesõnaline varumarstruut on kergem mõista kui tühi tabel, mis tagastab kättesaamatu tulemuse ja paneb rakenduse paistma katkisena, mitte valesti marsruuditud.

Esitage otsingule küsimus, mille esitab teie rakendus

ip route get lahendab tee; ip route show loetleb salvestatud kirjed, ja mõlemad võivad lahkneda, ilma et kumbki oleks vale. Lisage allika kontekst, sest allikapõhised reeglid sobivad ainult siis, kui otsing kannab allikat.

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

Esimene käsk esitab küsimuse hosti poolt. Teine lisab sisenemisliidese, mis on lähemal sellele, mida kogeb edastatav liiklus, ja vastus osutab sageli teisele tabelile. Kumbki sihtkoht ei ole reaalajas testiteenus; 198.51.100.23 on dokumentatsiooni aadress, seega asendage see hostiga, mida teil on lubatud sondeerida.

Isegi õige otsing tõestab ainult seda, et tee valiti. See ei ütle midagi selle kohta, kas vastaspool võtab liikluse vastu või kas vastus saab naasta sama arutluskäiguga.

Kus võrdlus pöördub

Hosti liiklus ja edastatav liiklus ei tee ainult erinevaid otsinguid; tagasiteel kohtavad nad erinevaid filtreid. Linux rakendab pöördtee valideerimist, kasutades rangemat kõigi liideste ja vastuvõtva liidese seadetest, seega ühe liidese väärtuse muutmine ei pruugi nähtavat mõju anda. Märgil põhinev marsruutimine lisab seose src_valid_mark, kus märk peab sobima, et allikas loetaks kehtivaks.

Kui vastused kaovad, samal ajal kui väljuv marsruutimine näib õige, lugege kehtivaid väärtusi enne nende puutumist, ja muutke neid ainult väljaöeldud poliitika põhjusel.

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

Valige kahe kavandi vahel tõendite põhjal: kui rakendus seob end PPP-aadressiga, piisab allika reeglist ja tabelist, mis hoiab peer-marsruuti. Kui karp edastab liiklust enda taga olevale LAN-ile, peavad ka sisenemiskontekst ja tagasitee sobima. Kui need ei sobi, parandage marsruudi omandit, selle asemel et kogu masina valideerimist lõdvendada.