PPP peer adresa ili VPN endpoint: koja ide u via

Jedna linija na PPP interfejsu rješava najveći dio raspreve o rutiranju na VPN kutiji: unutrašnja adresa i peer ispisan pored nje. Pročitajte taj par kao sićušnu podmrežu i tražit ćete gateway koji ne postoji. Pročitajte ga kao dva kraja jedne veze i sljedeći skok postaje očigledan. Poređenje ovdje je između ta dva čitanja, jer svaka tabela koju poslije izgradite nasljeđuje ono koje ste odabrali. Ništa o vanjskom VPN endpointu ne odlučuje nijedno od njih.

Dva čitanja jedne linije interfejsa

Uzmite sesiju u kojoj interfejs prijavljuje inet 10.64.3.9 peer 10.64.3.1/32. Čitanje kao podmreža tretira 10.64.3.9 kao usamljenog hosta na /32 ostrvu i zatim traži ruter da bi doseglo bilo šta izvan njega. Pošto je jedina druga adresa na vezi peer, to čitanje na kraju predlaže 10.64.3.9 sam kao gateway, što je cirkularno.

Čitanje kao endpoint je ono dokumentovano. Na point-to-point interfejsu peer imenuje udaljeni kraj te jedne veze, pa je 10.64.3.1 upotrebljiv sljedeći skok, a 10.64.3.9 je uvijek samo izvorna adresa.

Ta razlika određuje šta smije stajati u via. Upisivanje lokalne adrese tamo daje rutu koju kernel ne može razriješiti do susjeda, pa unos ili pada na validaciji ili guta saobraćaj dok u spisku izgleda savršeno zdravo. Peer funkcioniše jer je stvarna destinacija na vezi. Oba čitanja se slažu o vanjskom VPN endpointu, koji je potpuno zaseban identitet: do njega se dolazi kroz underlay, a ne kroz tunel koji završava.

Šta je sesija već instalirala

Prije nego što napišete bilo koju vlastitu tabelu, ispišite šta je došlo s vezom. Podržana PPP integracija obično instalira rutu uređaja i rutu peera tokom postavljanja sesije, a ta dva unosa već kodiraju ispravno čitanje.

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

Ruta uređaja kao 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ne nosi gateway jer je sam interfejs put. Ruta koja imenuje peer sa via je drugi objekat s drugim životnim vijekom, i nestaje kad sesija padne. Kopiranje bilo kojeg od ta dva oblika u trajnu tabelu bez provjere kako se ponovo instalira uobičajen je razlog zašto radni tunel izgubi rutu nakon ponovnog povezivanja.

Uporedite dva spiska umjesto da vjerujete pamćenju. Ako ruta peera postoji u main ali vaša dodatna tabela je prazna, naučili ste nešto što vam linija adrese nikad nije rekla.

Pravilo i tabela su odvojene odluke

Odabir tabele i njeno punjenje su nezavisni koraci, a poređenje je ovdje važno jer se to dvoje često pobrka pri otklanjanju grešaka. Pravilo koje šalje označeni saobraćaj u tabelu 100 ne čini ništa ako tabela 100 nema odgovarajuću rutu, a dobro popunjena tabela je nedostupna ako nijedno pravilo ne pokazuje na nju.

Pola default rute nije default ruta. Jedna 0.0.0.0/1 pokriva donju polovinu IPv4 prostora, pa politika koja namjerava uhvatiti sve treba i odgovarajuću 128.0.0.0/1, ili pravu default. Čitanje radne konfiguracije i kopiranje jedne od dvije polovine je kako ljudi završe s rutirajućom petljom koja se kvari samo na određenim destinacijama.

Ostavite namjerne izuzetke za adrese koje moraju ostati na LAN-u, i odlučite šta se dešava kad pretraga ne nađe ništa u odabranoj tabeli. Eksplicitna rezervna ruta je lakša za razmišljanje od prazne tabele, koja vraća nedostupan rezultat i čini da aplikacija izgleda pokvarena, a ne pogrešno rutirana.

Postavite pretrazi pitanje koje postavlja vaša aplikacija

ip route get razrješava putanju; ip route show prikazuje pohranjene unose, i njih dvoje se mogu ne slagati a da nijedno nije pogrešno. Uključite kontekst izvora, jer pravila zasnovana na izvoru odgovaraju samo kad pretraga nosi izvor.

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

Prva komanda postavlja pitanje sa hosta. Druga dodaje ulazni interfejs, što je bliže onome što proživljava proslijeđeni saobraćaj, a odgovor često pokazuje na drugu tabelu. Nijedna destinacija nije usluga za testiranje uživo; 198.51.100.23 je dokumentacijska adresa, pa je zamijenite hostom koji vam je dopušteno sondirati.

Čak i ispravna pretraga dokazuje samo da je putanja odabrana. Ne kaže ništa o tome da li druga strana prihvata saobraćaj ni da li odgovor može vratiti se istim rasuđivanjem.

Gdje se poređenje preokreće

Saobraćaj hosta i proslijeđeni saobraćaj ne uzimaju samo različite pretrage; oni na povratku susreću različite filtere. Linux primjenjuje validaciju obrnutog puta koristeći strožu od postavki za sve interfejse i za prijemni interfejs, pa promjena vrijednosti jednog interfejsa možda nema vidljivog efekta. Rutiranje zasnovano na oznaci dodaje relaciju src_valid_mark, u kojoj se oznaka mora poklopiti da bi izvor bio valjan.

Ako odgovori nestaju dok izlazno rutiranje izgleda ispravno, pročitajte efektivne vrijednosti prije nego što ih dotaknete, i mijenjajte ih samo s 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

Odaberite između dva dizajna na osnovu dokaza: ako se aplikacija veže na PPP adresu, dovoljno je pravilo izvora plus tabela koja drži rutu peera. Ako kutija prosljeđuje za LAN iza sebe, potrebno vam je i da se ulazni kontekst i povratni put slažu. Kad se ne slažu, ispravite vlasništvo rute umjesto da olabavite validaciju za cijelu mašinu.