PPP peer adrese vai VPN galapunkts: kura iet uz via
Salīdziniet PPP saskarnes lasīšanu kā apakštīklu ar tās inet un peer lasīšanu kā diviem saites galiem un skatiet, kuru nākamo lēcienu politikas tabula var pieņemt.
Viena rinda PPP saskarnē atrisina lielāko daļu maršrutēšanas strīda VPN kastē: iekšējā adrese un blakus uzdrukātais peer. Lasiet šo pāri kā mazu apakštīklu, un jūs meklēsiet vārteju, kas neeksistē. Lasiet to kā divus vienas saites galus, un nākamais lēciens kļūs acīmredzams. Salīdzinājums šeit ir starp šiem diviem lasījumiem, jo katra vēlāk būvētā tabula manto izvēlēto. Neko par ārējo VPN galapunktu neizlemj neviens no tiem.
Divi vienas saskarnes rindas lasījumi
Paņemiet sesiju, kurā saskarne ziņo inet 10.64.3.9 peer 10.64.3.1/32. Lasījums kā apakštīkls uzskata 10.64.3.9 par vientuļu saimnieku /32 salā un pēc tam meklē maršrutētāju, lai sasniegtu ko ārpus tās. Tā kā vienīgā otrā adrese saitē ir peer, šis lasījums galu galā piedāvā pašu 10.64.3.9 kā vārteju, kas ir apburtais loks.
Lasījums kā galapunkts ir dokumentētais. Punktuz punkta saskarnē peer nosauc tās vienas saites tālo galu, tāpēc 10.64.3.1 ir izmantojamais nākamais lēciens, bet 10.64.3.9 vienmēr ir tikai avota adrese.
Šī atšķirība nosaka, kas drīkst būt via. Vietējās adreses ierakstīšana tur rada maršrutu, kuru kodols nevar sasaistīt ar kaimiņu, tāpēc ieraksts vai nu neiztur validāciju, vai norij satiksmi, kamēr sarakstā izskatās pilnīgi vesels. Peer darbojas tāpēc, ka tas ir īsts galamērķis saitē. Abi lasījumi piekrīt ārējam VPN galapunktam, kas ir pilnīgi atsevišķa identitāte: to sasniedz caur underlay, nevis caur tuneli, kuru tas pabeidz.
Ko sesija jau ir instalējusi
Pirms rakstāt savu tabulu, izdrukājiet, kas nāca kopā ar saiti. Atbalstīta PPP integrācija parasti sesijas iestatīšanas laikā instalē ierīces maršrutu un peer maršrutu, un šie divi ieraksti jau kodē pareizo lasījumu.
ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5
Ierīces maršruts kā 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nenes vārteju, jo pati saskarne ir ceļš. Maršruts, kas nosauc peer ar via, ir cits objekts ar citu dzīves laiku, un tas pazūd, kad sesija krīt. Vienas no divām formām kopēšana pastāvīgā tabulā, nepārbaudot, kā tā tiek pārinstalēta, ir parastais iemesls, kāpēc strādājošs tunelis pēc atkārtotas savienošanas zaudē maršrutu.
Salīdziniet abus sarakstus, nevis paļaujieties uz atmiņu. Ja peer maršruts eksistē main, bet jūsu papildu tabula ir tukša, jūs uzzinājāt to, ko adreses rinda jums nekad neteica.
Noteikums un tabula ir atsevišķi lēmumi
Tabulas izvēle un tās aizpildīšana ir neatkarīgi soļi, un salīdzinājums šeit ir svarīgs, jo atkļūdošanas laikā šos divus bieži jauc. Noteikums, kas sūta atzīmēto satiksmi uz tabulu 100, neko nedara, ja tabulā 100 nav atbilstoša maršruta, un labi aizpildīta tabula ir nesasniedzama, ja uz to nenorāda neviens noteikums.
Puse noklusējuma maršruta nav noklusējuma maršruts. Viens 0.0.0.0/1 aptver IPv4 telpas apakšējo pusi, tāpēc politikai, kas paredzēta visu notvert, vajadzīgs arī atbilstošais 128.0.0.0/1 vai īsts default. Darba konfigurācijas izlasīšana un vienas no divām pusēm kopēšana ir veids, kā cilvēki nonāk pie maršrutēšanas cilpas, kas lūzt tikai noteiktos galamērķos.
Atstājiet apzinātus izņēmumus adresēm, kurām jāpaliek LAN tīklā, un izlemiet, kas notiek, kad meklēšana izvēlētajā tabulā neko neatrod. Skaidrs rezerves maršruts ir vieglāk pārdomājams nekā tukša tabula, kas atgriež nesasniedzamu rezultātu un liek lietotnei izskatīties salauztai, nevis nepareizi maršrutētai.
Uzdodiet meklēšanai jautājumu, ko uzdod jūsu lietotne
ip route get atrisina ceļu; ip route show uzskaita saglabātos ierakstus, un abi var nesaskanēt, lai gan neviens nav nepareizs. Iekļaujiet avota kontekstu, jo uz avotu balstīti noteikumi sakrīt tikai tad, kad meklēšana nes avotu.
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
Pirmā komanda uzdod jautājumu no saimnieka puses. Otrā pievieno ieejas saskarni, kas ir tuvāk tam, ko piedzīvo pārsūtītā satiksme, un atbilde bieži norāda uz citu tabulu. Neviens no galamērķiem nav dzīvs testa pakalpojums; 198.51.100.23 ir dokumentācijas adrese, tāpēc aizstājiet to ar saimnieku, kuru jums ir atļauts sondēt.
Pat pareiza meklēšana pierāda tikai to, ka ceļš tika izvēlēts. Tā neko nepasaka par to, vai pretējā puse pieņem satiksmi vai vai atbilde var atgriezties ar to pašu spriedumu.
Kur salīdzinājums apgāžas
Saimnieka satiksme un pārsūtītā satiksme ne tikai veic dažādas meklēšanas; atceļā tās sastop dažādus filtrus. Linux piemēro apgrieztā ceļa validāciju, izmantojot stingrāko no visu saskarņu un uztverošās saskarnes iestatījumiem, tāpēc vienas saskarnes vērtības maiņa var nedot redzamu efektu. Maršrutēšana pēc atzīmes pievieno attiecības src_valid_mark, kurās atzīmei jāsakrīt, lai avots tiktu uzskatīts par derīgu.
Ja atbildes pazūd, kamēr izejošā maršrutēšana izskatās pareiza, izlasiet faktiskās vērtības pirms tām pieskaraties, un mainiet tās tikai ar norādītu politikas iemeslu.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark
Izvēlieties starp abiem projektiem, pamatojoties uz pierādījumiem: ja lietotne piesaistās PPP adresei, pietiek ar avota noteikumu un tabulu, kurā ir peer maršruts. Ja kaste pārsūta satiksmi LAN tīklam aiz tās, jums arī jābūt, lai ieejas konteksts un atgriešanās ceļš sakristu. Kad tie nesakrīt, izlabojiet maršruta piederību, nevis atlaidiet validāciju visai mašīnai.