PPP-peer-adreso aŭ VPN-finpunkto: kiu eniras en via

Unu linio sur PPP-interfaco solvas la plej grandan parton de la enkursiga diskuto sur VPN-skatolo: la interna adreso kaj la peer presita apud ĝi. Legu tiun paron kiel malgrandegan subreton kaj vi serĉos pordegon, kiu ne ekzistas. Legu ĝin kiel la du finojn de unu ligilo kaj la sekva salteto fariĝas evidenta. La komparo ĉi tie estas inter tiuj du legmanieroj, ĉar ĉiu tabelo, kiun vi konstruos poste, heredas tiun, kiun vi elektis. Nenio pri la ekstera VPN-finpunkto estas decidata de iu el ili.

Du legmanieroj de unu interfaca linio

Prenu sesion, en kiu la interfaco raportas inet 10.64.3.9 peer 10.64.3.1/32. La subreta legmaniero traktas 10.64.3.9 kiel solan gastiganton sur /32-insulo kaj poste serĉas enkursigilon por atingi ion trans ĝi. Ĉar la sola alia adreso sur la ligilo estas la peer, tiu legmaniero finas proponante 10.64.3.9 mem kiel pordegon, kio estas cirkla.

La finpunkta legmaniero estas la dokumentita. Sur punkt-al-punkta interfaco, peer nomas la malproksiman finon de tiu unu ligilo, do 10.64.3.1 estas la uzebla sekva salteto kaj 10.64.3.9 estas ĉiam nur fonta adreso.

Tiu diferenco regas, kio povas aperi en via. Skribi la lokan adreson tie produktas itineron, kiun la kerno ne povas solvi al najbaro, do la enskribo aŭ malsukcesas la validigon aŭ englutas trafikon dum ĝi aspektas tute sana en listo. La peer funkcias ĉar ĝi estas reala celo sur la ligilo. Ambaŭ legmanieroj konsentas pri la ekstera VPN-finpunkto, kiu estas tute aparta identeco: ĝi estas atingata tra la underlay, ne tra la tunelo, kiun ĝi finas.

Kion la sesio jam instalas

Antaŭ ol skribi propran tabelon, presu tion, kio venis kun la ligilo. Subtenata PPP-integriĝo kutime instalas aparatan itineron kaj peer-itineron dum la sesia agordo, kaj tiuj du enskriboj jam kodas la ĝustan legmanieron.

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

Aparata itinero kiel 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 portas neniun pordegon ĉar la interfaco mem estas la vojo. Itinero, kiu nomas la peer per via, estas alia objekto kun alia vivdaŭro, kaj ĝi malaperas, kiam la sesio falas. Kopii iun el la du formoj en persistentan tabelon sen kontroli, kiel ĝi estas reinstalata, estas la kutima kialo, kial funkcianta tunelo perdas sian itineron post rekonekto.

Komparu la du listojn anstataŭ fidi la memoron. Se la peer-itinero ekzistas en main sed via aldona tabelo estas malplena, vi lernis ion, kion la adreslinio neniam diris al vi.

Regulo kaj tabelo estas apartaj decidoj

Elekti tabelon kaj plenigi ĝin estas sendependaj paŝoj, kaj la komparo gravas ĉi tie ĉar la du ofte konfuziĝas dum sencimigado. Regulo, kiu sendas markitan trafikon al tabelo 100, faras nenion se tabelo 100 ne havas konforman itineron, kaj bone plenigita tabelo estas neatingebla se neniu regulo montras al ĝi.

Duona defaŭlta itinero ne estas defaŭlta itinero. Unu sola 0.0.0.0/1 kovras la malsupran duonon de la IPv4-spaco, do politiko, kiu intencas kapti ĉion, bezonas ankaŭ la konforman 128.0.0.0/1, aŭ veran default. Legi funkciantan agordon kaj kopii unu el la du duonoj estas kiel homoj finas kun enkursiga buklo, kiu rompiĝas nur ĉe certaj celoj.

Lasu intencajn esceptojn por la adresoj, kiuj devas resti en la LAN, kaj decidu, kio okazas, kiam la serĉado trovas nenion en la elektita tabelo. Klara rezerva itinero estas pli facile pripensebla ol malplena tabelo, kiu redonas neatingeblan rezulton kaj igas la aplikaĵon aspekti rompita anstataŭ malĝuste enkursigita.

Demandu al la serĉado la demandon, kiun demandas via aplikaĵo

ip route get solvas vojon, ip route show listigas konservitajn enskribojn, kaj la du povas malkonsenti sen ke iu ajn estas malĝusta. Inkluzivu la fontan kuntekston, ĉar reguloj bazitaj sur fonto kongruas nur kiam la serĉado portas fonton.

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

La unua komando starigas la demandon de la gastiganto. La dua aldonas enigan interfacon, kiu estas pli proksima al tio, kion spertas plusendita trafiko, kaj la respondo ofte montras al alia tabelo. Neniu el la celoj estas viva testa servo; 198.51.100.23 estas dokumenta adreso, do anstataŭigu ĝin per gastiganto, kiun vi rajtas sondi.

Eĉ ĝusta serĉado pruvas nur, ke vojo estis elektita. Ĝi diras nenion pri tio, ĉu la alia flanko akceptas la trafikon aŭ ĉu la respondo povas reveni per la sama rezonado.

Kie la komparo renversiĝas

Gastiganta trafiko kaj plusendita trafiko ne nur faras malsamajn serĉadojn; ili renkontas malsamajn filtrilojn sur la revena vojo. Linux aplikas inversvojan validigon uzante la plej striktan el la agordoj de ĉiuj interfacoj kaj de la akcepta interfaco, do ŝanĝo de la valoro de unu interfaco eble havas neniun videblan efikon. Marka enkursigado aldonas la rilaton src_valid_mark, kie la marko devas kongrui por ke fonto estu konsiderata valida.

Se respondoj malaperas dum la elira enkursigado aspektas ĝusta, legu la efikajn valorojn antaŭ ol tuŝi ilin, kaj ŝanĝu ilin nur kun deklarita politika kaŭzo.

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

Elektu inter la du dezajnoj surbaze de pruvoj: se la aplikaĵo ligiĝas al la PPP-adreso, fonta regulo plus tabelo tenanta la peer-itineron sufiĉas. Se la skatolo plusendas por LAN malantaŭ ĝi, vi ankaŭ bezonas, ke la eniga kunteksto kaj la revena vojo konsentu. Kiam ili ne konsentas, riparu la posedon de la itinero anstataŭ malfaciligi la validigon por la tuta maŝino.