Peer address ng PPP o VPN endpoint: alin ang napupunta sa via

Isang linya sa PPP interface ang nagtatapos sa halos lahat ng pagtatalo sa routing sa isang VPN box: ang panloob na address at ang peer na nakalimbag sa tabi nito. Basahin ang pares na iyon bilang maliit na subnet at maghahanap ka ng gateway na wala naman. Basahin ito bilang dalawang dulo ng isang link at nagiging halata ang susunod na hop. Ang paghahambing dito ay sa pagitan ng dalawang pagbasang iyon, dahil bawat table na itatayo mo mamaya ay namamana ang pinili mo. Wala sa kanila ang nagpapasya tungkol sa panlabas na VPN endpoint.

Dalawang pagbasa sa isang linya ng interface

Kumuha ng session kung saan iniuulat ng interface ang inet 10.64.3.9 peer 10.64.3.1/32. Itinuturing ng pagbasang subnet ang 10.64.3.9 bilang nag-iisang host sa isang /32 isla at pagkatapos ay naghahanap ng router para maabot ang anumang nasa labas nito. Dahil ang tanging iba pang address sa link ay ang peer, nauuwi ang pagbasang iyon sa pagmumungkahi ng 10.64.3.9 mismo bilang gateway, na paikot.

Ang pagbasang endpoint ang dokumentado. Sa point-to-point interface, pinapangalanan ng peer ang malayong dulo ng nag-iisang link na iyon, kaya ang 10.64.3.1 ang magagamit na susunod na hop at ang 10.64.3.9 ay laging address ng pinagmulan lamang.

Ang pagkakaibang iyon ang nagtatakda kung ano ang maaaring nasa via. Ang pagsulat ng lokal na address doon ay gumagawa ng rutang hindi maresolba ng kernel sa isang kapitbahay, kaya ang entry ay nabigo sa validation o lumalamon ng trapiko habang mukhang ganap na malusog sa isang listahan. Gumagana ang peer dahil tunay itong destinasyon sa link. Sumasang-ayon ang dalawang pagbasa tungkol sa panlabas na VPN endpoint, na isang ganap na hiwalay na pagkakakilanlan: naaabot ito sa pamamagitan ng underlay, hindi sa tunnel na tinatapos nito.

Ano ang na-install na ng session

Bago magsulat ng sariling table, i-print kung ano ang kasama ng link. Karaniwang nag-i-install ang suportadong PPP integration ng device route at peer route habang isinasayos ang session, at ang dalawang entry na iyon ay nagko-code na ng tamang pagbasa.

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

Ang device route na tulad ng 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ay walang gateway dahil ang interface mismo ang daan. Ang rutang nagpapangalan sa peer gamit ang via ay ibang object na may ibang habang-buhay, at nawawala ito kapag bumagsak ang session. Ang pagkopya ng alinman sa dalawang anyo sa isang persistenteng table nang hindi sinusuri kung paano ito muling ini-install ang karaniwang dahilan kung bakit nawawala ng gumaganang tunnel ang ruta nito pagkatapos ng muling pagkonekta.

Ihambing ang dalawang listahan sa halip na magtiwala sa memorya. Kung umiiral ang peer route sa main ngunit walang laman ang dagdag na table mo, may natutunan kang hindi kailanman sinabi sa iyo ng linya ng address.

Ang tuntunin at table ay magkahiwalay na pasya

Ang pagpili ng table at pagpuno nito ay magkahiwalay na hakbang, at mahalaga ang paghahambing dito dahil madalas silang napagkakamalan habang nagde-debug. Ang tuntuning nagpapadala ng minarkahang trapiko sa table 100 ay walang ginagawa kung walang tugmang ruta sa table 100, at ang punong-punong table ay hindi maabot kung walang tuntuning nakaturo dito.

Ang kalahati ng default route ay hindi default route. Ang isang 0.0.0.0/1 ay sumasaklaw sa ibabang kalahati ng IPv4 space, kaya ang policy na naglalayong hulihin ang lahat ay nangangailangan din ng tutugmang 128.0.0.0/1, o tunay na default. Ang pagbasa ng gumaganang configuration at pagkopya ng isa sa dalawang kalahati ang paraan ng mga tao para mapunta sa routing loop na nasisira lamang sa ilang destinasyon.

Mag-iwan ng sinadyang pagbubukod para sa mga address na dapat manatili sa LAN, at magpasya kung ano ang mangyayari kapag walang natagpuan ang paghahanap sa piniling table. Ang malinaw na fallback route ay mas madaling isipin kaysa sa walang laman na table, na nagbabalik ng hindi maabot na resulta at nagpapamukhang sira ang aplikasyon sa halip na maling naka-ruta.

Itanong sa paghahanap ang tanong na itinatatong ng aplikasyon mo

ip route get ay naglulutas ng landas; ang ip route show ay naglilista ng mga naka-imbak na entry, at ang dalawa ay maaaring hindi magkasundo nang walang mali sa alinman. Isama ang konteksto ng pinagmulan, dahil tumutugma lamang ang mga tuntuning nakabatay sa pinagmulan kapag may dalang pinagmulan ang paghahanap.

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

Ang unang utos ay nagtatanong mula sa host. Ang pangalawa ay nagdaragdag ng papasok na interface, na mas malapit sa nararanasan ng itinataguyod na trapiko, at madalas na itinuturo ng sagot ang ibang table. Wala sa mga destinasyon ang live na testing service; ang 198.51.100.23 ay documentation address, kaya palitan ito ng host na pinapayagan kang siyasatin.

Kahit ang tamang paghahanap ay nagpapatunay lamang na may napiling landas. Wala itong sinasabi tungkol sa kung tinatanggap ng kabilang panig ang trapiko o kung makababalik ang sagot sa parehong pangangatwiran.

Saan bumabaligtad ang paghahambing

Ang trapiko ng host at itinataguyod na trapiko ay hindi lamang kumukuha ng magkaibang paghahanap; nahaharap sila sa magkaibang filter sa pagbabalik. Inilalapat ng Linux ang reverse-path validation gamit ang mas mahigpit sa mga setting ng lahat ng interface at ng tumatanggap na interface, kaya ang pagbabago ng halaga ng isang interface ay maaaring walang nakikitang epekto. Ang routing na nakabatay sa marka ay nagdaragdag ng ugnayang src_valid_mark, kung saan dapat tumugma ang marka para maituring na wasto ang isang pinagmulan.

Kung naglalaho ang mga sagot habang mukhang tama ang palabas na routing, basahin ang epektibong halaga bago ito hawakan, at baguhin lamang ang mga ito kapag may nakasaad na dahilan ng policy.

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

Pumili sa pagitan ng dalawang disenyo batay sa ebidensya: kung nakakabit ang aplikasyon sa PPP address, sapat na ang tuntunin ng pinagmulan at table na may peer route. Kung nagpapatuloy ang kahon para sa LAN sa likod nito, kailangan mo rin na tugma ang papasok na konteksto at ang daan pabalik. Kapag hindi sila tugma, ayusin ang pagmamay-ari ng ruta sa halip na luwagan ang validation para sa buong makina.