PPP peer adresas ar VPN galinis taškas: kuris eina į via

Viena eilutė PPP sąsajoje išsprendžia didžiąją dalį maršrutizavimo ginčo VPN dėžėje: vidinis adresas ir šalia jo atspausdintas peer. Skaitykite šią porą kaip mažytį potinklį ir ieškosite šliuzo, kurio nėra. Skaitykite ją kaip du vienos jungties galus ir kitas šuolis taps akivaizdus. Palyginimas čia yra tarp šių dviejų skaitymų, nes kiekviena vėliau pastatyta lentelė paveldi pasirinktąjį. Niekas apie išorinį VPN galinį tašką nėra sprendžiama nė vieno iš jų.

Du vienos sąsajos eilutės skaitymai

Paimkite sesiją, kurioje sąsaja praneša inet 10.64.3.9 peer 10.64.3.1/32. Skaitymas kaip potinklis traktuoja 10.64.3.9 kaip vienišą mazgą /32 saloje ir tada ieško maršrutizatoriaus, kad pasiektų ką nors už jos. Kadangi vienintelis kitas adresas jungtyje yra peer, šis skaitymas galiausiai siūlo patį 10.64.3.9 kaip šliuzą, o tai yra uždaras ratas.

Skaitymas kaip galinis taškas yra dokumentuotasis. Taškas-taškas sąsajoje peer įvardija tolimąjį tos vienos jungties galą, todėl 10.64.3.1 yra tinkamas kitas šuolis, o 10.64.3.9 visada yra tik šaltinio adresas.

Šis skirtumas lemia, kas gali būti via. Įrašius ten vietinį adresą gaunamas maršrutas, kurio branduolys negali susieti su kaimynu, todėl įrašas arba nepraeina patikros, arba praryja srautą, nors sąraše atrodo visiškai sveikas. Peer veikia todėl, kad tai tikras paskirties taškas jungtyje. Abu skaitymai sutaria dėl išorinio VPN galinio taško, kuris yra visiškai atskira tapatybė: jo pasiekiama per underlay, o ne per tunelį, kurį jis užbaigia.

Ką sesija jau įdiegė

Prieš rašydami savo lentelę, išspausdinkite, kas atėjo su jungtimi. Palaikoma PPP integracija paprastai sesijos nustatymo metu įdiegia įrenginio maršrutą ir peer maršrutą, ir šie du įrašai jau koduoja teisingą skaitymą.

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

Įrenginio maršrutas kaip 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 neturi šliuzo, nes pati sąsaja yra kelias. Maršrutas, kuris įvardija peer per via, yra kitas objektas su kitu gyvavimo laiku, ir jis išnyksta, kai sesija nutrūksta. Vienos iš dviejų formų kopijavimas į nuolatinę lentelę nepatikrinus, kaip ji įdiegiama iš naujo, yra įprasta priežastis, kodėl veikiantis tunelis po pakartotinio prisijungimo praranda maršrutą.

Palyginkite abu sąrašus, o ne pasikliaukite atmintimi. Jei peer maršrutas yra main, o jūsų papildoma lentelė tuščia, sužinojote tai, ko adreso eilutė jums niekada nesakė.

Taisyklė ir lentelė yra atskiri sprendimai

Lentelės pasirinkimas ir jos užpildymas yra nepriklausomi žingsniai, o palyginimas čia svarbus, nes derinant šie du dažnai painiojami. Taisyklė, siunčianti pažymėtą srautą į 100 lentelę, nieko nedaro, jei 100 lentelėje nėra atitinkančio maršruto, o gerai užpildyta lentelė yra nepasiekiama, jei į ją nenurodo jokia taisyklė.

Pusė numatytojo maršruto nėra numatytasis maršrutas. Vienas 0.0.0.0/1 apima apatinę IPv4 erdvės pusę, todėl politikai, kuri ketina sugauti viską, reikia ir atitinkamo 128.0.0.0/1, arba tikro default. Perskaityti veikiančią konfigūraciją ir nukopijuoti vieną iš dviejų pusių yra būdas, kuriuo žmonės gauna maršrutizavimo kilpą, kuri lūžta tik tam tikruose paskirties taškuose.

Palikite tyčines išimtis adresams, kurie turi likti LAN tinkle, ir nuspręskite, kas nutinka, kai paieška pasirinktoje lentelėje nieko neranda. Aiškus atsarginis maršrutas yra lengviau apgalvojamas nei tuščia lentelė, kuri grąžina nepasiekiamą rezultatą ir leidžia programai atrodyti sugedusiai, o ne neteisingai maršrutizuotai.

Užduokite paieškai klausimą, kurį užduoda jūsų programa

ip route get išsprendžia kelią; ip route show išvardija saugomus įrašus, ir abu gali nesutarti, nors nė vienas nėra klaidingas. Įtraukite šaltinio kontekstą, nes šaltiniu pagrįstos taisyklės sutampa tik tada, kai paieška neša šaltinį.

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

Pirmoji komanda užduoda klausimą iš mazgo pusės. Antroji prideda įvesties sąsają, o tai arčiau to, ką patiria persiunčiamas srautas, ir atsakymas dažnai nurodo kitą lentelę. Nė vienas paskirties taškas nėra gyva testavimo paslauga; 198.51.100.23 yra dokumentacijos adresas, todėl pakeiskite jį mazgu, kurį jums leidžiama tirti.

Net teisinga paieška įrodo tik tai, kad kelias buvo pasirinktas. Ji nieko nesako apie tai, ar priešinga pusė priima srautą, ar atsakymas gali grįžti tuo pačiu samprotavimu.

Kur palyginimas apsiverčia

Mazgo srautas ir persiunčiamas srautas ne tik atlieka skirtingas paieškas; grįždami jie sutinka skirtingus filtrus. Linux taiko atvirkštinio kelio patikrą naudodamas griežtesnį iš visų sąsajų ir priimančios sąsajos nustatymų, todėl vienos sąsajos vertės pakeitimas gali neturėti matomo poveikio. Maršrutizavimas pagal žymą prideda ryšį src_valid_mark, kuriame žyma turi sutapti, kad šaltinis būtų laikomas galiojančiu.

Jei atsakymai dingsta, o išeinantis maršrutizavimas atrodo teisingai, perskaitykite veikiančias vertes prieš jas liesdami, ir keiskite jas tik su nurodyta politikos priežastimi.

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

Rinkitės tarp dviejų projektų remdamiesi įrodymais: jei programa prisiriša prie PPP adreso, pakanka šaltinio taisyklės ir lentelės su peer maršrutu. Jei dėžė persiunčia srautą už jos esančiam LAN tinklui, reikia ir to, kad įvesties kontekstas bei grįžimo kelias sutaptų. Kai jie nesutampa, pataisykite maršruto priklausomybę, o ne atlaisvinkite patikrą visai mašinai.