Adresa peer PPP apo pika fundore VPN: cila shkon në via

Një rresht i vetëm në një ndërfaqe PPP zgjidh pjesën më të madhe të debatit të rrugëtimit në një kuti VPN: adresa e brendshme dhe peer-i i shtypur pranë saj. Lexojeni atë çift si një nënrrjet të vogël dhe do të kërkoni një portë që nuk ekziston. Lexojeni si dy skajet e një lidhjeje të vetme dhe hapi tjetër bëhet i dukshëm. Krahasimi këtu është midis këtyre dy leximeve, sepse çdo tabelë e ndërtuar më pas trashëgon atë që zgjidhët. Asnjëra prej tyre nuk vendos gjë për pikën fundore të jashtme të VPN.

Dy lexime të një rreshti ndërfaqeje

Merrni një sesion në të cilin ndërfaqja raporton inet 10.64.3.9 peer 10.64.3.1/32. Leximi si nënrrjet e trajton 10.64.3.9 si një host të vetmuar në një ishull /32 dhe pastaj kërkon një rrugëtues për të arritur diçka përtej tij. Meqenëse adresa e vetme tjetër në lidhje është peer-i, ky lexim përfundon duke propozuar vetë 10.64.3.9 si portë, gjë që është rrethore.

Leximi si pikë fundore është ai i dokumentuar. Në një ndërfaqe pikë-për-pikë, peer emërton skajin e largët të asaj lidhjeje të vetme, prandaj 10.64.3.1 është hapi tjetër i përdorshëm dhe 10.64.3.9 është gjithmonë vetëm një adresë burimi.

Ky ndryshim përcakton çfarë mund të shfaqet në via. Shkrimi i adresës lokale atje prodhon një rrugë që kerneli nuk mund ta zgjidhë drejt një fqinji, kështu që zëri ose dështon në validim ose gëlltit trafik ndërsa duket plotësisht i shëndetshëm në një listë. Peer-i funksionon sepse është destinacion i vërtetë në lidhje. Të dy leximet pajtohen për pikën fundore të jashtme të VPN, e cila është një identitet plotësisht i veçantë: arrihet përmes underlay, jo përmes tunelit që ajo përfundon.

Çfarë ka instaluar tashmë sesioni

Përpara se të shkruani ndonjë tabelë tuajën, shtypni çfarë erdhi me lidhjen. Një integrim PPP i mbështetur zakonisht instalon një rrugë pajisjeje dhe një rrugë peer gjatë konfigurimit të sesionit, dhe këto dy zëra tashmë kodojnë leximin e saktë.

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

Një rrugë pajisjeje si 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nuk mban portë sepse vetë ndërfaqja është rruga. Një rrugë që e emërton peer-in me via është një objekt tjetër me jetëgjatësi tjetër, dhe zhduket kur sesioni bie. Kopjimi i njërës prej dy formave në një tabelë të përhershme pa kontrolluar si riinstalohet është arsyeja e zakonshme pse një tunel që funksiononte humbet rrugën e tij pas një rilidhjeje.

Krahasoni dy listat në vend që t'i besoni kujtesës. Nëse rruga e peer-it ekziston në main por tabela juaj shtesë është bosh, keni mësuar diçka që rreshti i adresës nuk ju tha kurrë.

Rregulli dhe tabela janë vendime të ndara

Zgjedhja e një tabele dhe mbushja e saj janë hapa të pavarur, dhe krahasimi ka rëndësi këtu sepse të dyen shpesh ngatërrohen gjatë korrigjimit. Një rregull që dërgon trafik të shënuar në tabelën 100 nuk bën asgjë nëse tabela 100 nuk ka një rrugë përputhëse, dhe një tabelë e mbushur mirë është e paarritshme nëse asnjë rregull nuk tregon drejt saj.

Gjysma e një rrugë të parazgjedhur nuk është rrugë e parazgjedhur. Një 0.0.0.0/1 i vetëm mbulon gjysmën e poshtme të hapësirës IPv4, prandaj një politikë që synon të kapë gjithçka ka nevojë edhe për 128.0.0.0/1 përputhës, ose për një default të vërtetë. Leximi i një konfigurimi që funksionon dhe kopjimi i njërës prej dy gjysmave është mënyra se si njerëzit përfundojnë me një lak rrugëtimi që thyhet vetëm në disa destinacione.

Lini përjashtime të qëllimshme për adresat që duhet të qëndrojnë në LAN, dhe vendosni çfarë ndodh kur kërkimi nuk gjen asgjë në tabelën e zgjedhur. Një rrugë rezervë e qartë është më e lehtë për t'u menduar sesa një tabelë bosh, e cila kthen një rezultat të paarritshëm dhe e bën aplikacionin të duket i prishur në vend të keqrrugëtuar.

Bëjini kërkimit pyetjen që bën aplikacioni juaj

ip route get zgjidh një shteg; ip route show liston zërat e ruajtur, dhe të dyen mund të mos pajtohen pa qenë asnjëri i gabuar. Përfshini kontekstin e burimit, sepse rregullat e bazuara në burim përputhen vetëm kur kërkimi mbart një burim.

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

Komanda e parë e bën pyetjen nga hosti. E dyta shton një ndërfaqe hyrëse, e cila është më afër asaj që përjeton trafiku i përçuar, dhe përgjigjja shpesh tregon një tabelë tjetër. Asnjëri destinacion nuk është shërbim prove i drejtpërdrejtë; 198.51.100.23 është adresë dokumentacioni, prandaj zëvendësojeni me një host që ju lejohet të sondoni.

Edhe një kërkim i saktë provon vetëm se një shteg u zgjodh. Nuk thotë asgjë për atë nëse pala tjetër e pranon trafikun ose nëse përgjigjja mund të kthehet përmes të njëjtit arsyetim.

Ku kthehet krahasimi

Trafiku i hostit dhe trafiku i përçuar jo vetëm që bëjnë kërkime të ndryshme; në rrugën e kthimit ata ndeshen me filtra të ndryshëm. Linux zbaton validimin e shtegut të kundërt duke përdorur më të rreptin e cilësimeve për të gjitha ndërfaqet dhe për ndërfaqen pritëse, prandaj ndryshimi i vlerës së një ndërfaqeje mund të mos ketë efekt të dukshëm. Rrugëtimi i bazuar në shenjë shton relacionin src_valid_mark, ku shenja duhet të përputhet që një burim të konsiderohet i vlefshëm.

Nëse përgjigjjet zhduken ndërsa rrugëtimi dalës duket i saktë, lexoni vlerat efektive përpara se t'i prekni, dhe ndryshojini vetëm me një arsye politike të deklaruar.

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

Zgjidhni midis dy modeleve mbi bazë provash: nëse aplikacioni lidhet me adresën PPP, mjaftojnë një rregull burimi plus një tabelë që mban rrugën e peer-it. Nëse kutia përçon për një LAN pas saj, ju duhet gjithashtu që konteksti hyrës dhe shtegu i kthimit të pajtohen. Kur nuk pajtohen, korrigjoni pronësinë e rrugës në vend që të lironi validimin për të gjithë makinën.