Naslov peer PPP proti končni točki VPN: katera gre v via

Ena sama vrstica na vmesniku PPP razreši večino razprave o usmerjanju na škatli VPN: notranji naslov in peer, izpisan ob njem. Berite ta par kot drobno podomrežje in iskali boste prehod, ki ne obstaja. Berite ga kot dva konca ene same povezave in naslednji skok postane očiten. Primerjava tukaj je med tema dvema branjema, ker vsaka tabela, zgrajena pozneje, podeduje tisto, ki ste jo izbrali. Ničesar o zunanji končni točki VPN ne odloči nobeno od njiju.

Dve branji ene vrstice vmesnika

Vzemite sejo, v kateri vmesnik poroča inet 10.64.3.9 peer 10.64.3.1/32. Branje kot podomrežje obravnava 10.64.3.9 kot osamljenega gostitelja na otoku /32 in nato išče usmerjevalnik, da bi doseglo karkoli onkraj njega. Ker je edini drugi naslov na povezavi peer, to branje na koncu predlaga 10.64.3.9 samega kot prehod, kar je krožno.

Branje kot končna točka je dokumentirano. Na vmesniku od točke do točke peer poimenuje oddaljeni konec te ene povezave, zato je 10.64.3.1 uporaben naslednji skok, 10.64.3.9 pa je vedno le izvorni naslov.

Ta razlika določa, kaj sme stati v via. Če tja vpišete lokalni naslov, dobite pot, ki je jedro ne more razrešiti do soseda, zato vnos bodisi pade na preverjanju bodisi pogoltne promet, medtem ko je na seznamu videti popolnoma zdrav. Peer deluje, ker je resnična ciljna točka na povezavi. Obe branji se strinjata glede zunanje končne točke VPN, ki je povsem ločena identiteta: dosežemo jo skozi underlay, ne skozi tunel, ki ga zaključuje.

Kaj je seja že namestila

Preden napišete katero koli svojo tabelo, izpišite, kaj je prišlo s povezavo. Podprta integracija PPP običajno med nastavljanjem seje namesti pot naprave in pot peer, in ta dva vnosa že kodirata pravilno branje.

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

Pot naprave, kot je 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9, ne nosi prehoda, ker je vmesnik sam pot. Pot, ki poimenuje peer s via, je drug predmet z drugo življenjsko dobo in izgine, ko seja pade. Kopiranje katere koli od teh dveh oblik v trajno tabelo brez preverjanja, kako se znova namesti, je običajen razlog, da delujoč tunel po ponovni povezavi izgubi svojo pot.

Primerjajte oba izpisa, namesto da zaupate spominu. Če pot peer obstaja v main, vaša dodatna tabela pa je prazna, ste se naučili nekaj, česar vam vrstica naslova ni nikoli povedala.

Pravilo in tabela sta ločeni odločitvi

Izbrati tabelo in jo napolniti sta neodvisna koraka, primerjava pa je tu pomembna, ker se oboje pri odpravljanju napak pogosto zamenja. Pravilo, ki pošilja označen promet v tabelo 100, ne naredi nič, če tabela 100 nima ustrezne poti, in dobro napolnjena tabela je nedosegljiva, če nanjo ne kaže nobeno pravilo.

Polovica privzete poti ni privzeta pot. Ena sama 0.0.0.0/1 pokriva spodnjo polovico prostora IPv4, zato politika, ki namerava ujeti vse, potrebuje tudi ustrezno 128.0.0.0/1, ali pravo default. Prebrati delujočo konfiguracijo in kopirati eno od dveh polovic je način, kako ljudje končajo z zanko usmerjanja, ki se zlomi le pri določenih ciljih.

Pustite namerne izjeme za naslove, ki morajo ostati v LAN, in določite, kaj se zgodi, ko iskanje v izbrani tabeli ne najde ničesar. Izrecna rezervna pot je lažja za razmišljanje kot prazna tabela, ki vrne nedosegljiv rezultat in naredi aplikacijo videti pokvarjeno namesto napačno usmerjeno.

Iskanju postavite vprašanje, ki ga postavlja vaša aplikacija

ip route get razreši pot; ip route show izpiše shranjene vnose, in oba se lahko razhajata, ne da bi bil eden napačen. Vključite kontekst vira, ker se pravila, ki temeljijo na viru, ujemajo le, ko iskanje nosi vir.

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

Prvi ukaz postavi vprašanje z gostitelja. Drugi doda vhodni vmesnik, kar je bliže temu, kar doživlja posredovani promet, in odgovor pogosto pokaže na drugo tabelo. Noben od ciljev ni živa testna storitev; 198.51.100.23 je dokumentacijski naslov, zato ga zamenjajte z gostiteljem, ki ga smete sondirati.

Tudi pravilno iskanje dokaže le, da je bila izbrana pot. Ne pove ničesar o tem, ali druga stran promet sprejema ali ali se odgovor lahko vrne po istem sklepanju.

Kje se primerjava obrne

Promet gostitelja in posredovani promet ne izbirata le različnih iskanj; na poti nazaj naletita na različne filtre. Linux uveljavlja preverjanje obrnjene poti z uporabo strožje od nastavitev za vse vmesnike in za sprejemni vmesnik, zato sprememba vrednosti enega vmesnika morda nima vidnega učinka. Usmerjanje na podlagi oznake doda razmerje src_valid_mark, kjer se mora oznaka ujemati, da vir velja za veljavnega.

Če odgovori izginjajo, medtem ko je odhodno usmerjanje videti pravilno, preberite dejanske vrednosti, preden se jih dotaknete, in jih spremenite le z navedenim razlogom politike.

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

Med obema zasnovama izberite na podlagi dokazov: če se aplikacija veže na naslov PPP, zadostujeta pravilo vira in tabela, ki drži pot peer. Če škatla posreduje promet za LAN za seboj, potrebujete tudi, da se vhodni kontekst in povratna pot ujemata. Ko se ne ujemata, popravite lastništvo poti, namesto da omilite preverjanje za celoten stroj.