PPP peer -osoite vai VPN-päätepiste: kumpi menee via-kenttään

Yksi rivi PPP-liitännällä ratkaisee suurimman osan VPN-laatikon reitityskiistasta: sisäinen osoite ja sen viereen tulostettu peer. Lue tämä pari pienenä aliverkkona ja etsit yhdyskäytävää, jota ei ole. Lue se yhden linkin kahtena päänä ja seuraava hyppy tulee ilmeiseksi. Vertailu on tässä näiden kahden lukutavan välillä, koska jokainen myöhemmin rakennettu taulu perii valitsemasi. Kumpikaan niistä ei päätä mitään ulkoisesta VPN-päätepisteestä.

Kaksi lukutapaa yhdestä liitännän rivistä

Ota istunto, jossa liitäntä ilmoittaa inet 10.64.3.9 peer 10.64.3.1/32. Aliverkkolukutapa kohtelee 10.64.3.9:ää yksinäisenä isäntänä /32-saarella ja etsii sitten reitittimen päästäkseen johonkin sen ulkopuolelle. Koska linkin ainoa muu osoite on peer, tämä lukutapa ehdottaa lopulta 10.64.3.9:ää itseään yhdyskäytäväksi, mikä on kehäpäätelmä.

Päätepistelukutapa on dokumentoitu. Piste-piste-liitännällä peer nimeää tuon yhden linkin kauemman pään, joten 10.64.3.1 on käyttökelpoinen seuraava hyppy ja 10.64.3.9 on aina vain lähdeosoite.

Tämä ero määrää, mitä via saa sisältää. Paikallisen osoitteen kirjoittaminen sinne tuottaa reitin, jota ydin ei voi ratkaista naapuriksi, joten merkintä joko epäonnistuu validoinnissa tai nielee liikennettä näyttäen samalla listassa täysin terveeltä. Peer toimii, koska se on todellinen kohde linkillä. Molemmat lukutavat ovat samaa mieltä ulkoisesta VPN-päätepisteestä, joka on täysin erillinen identiteetti: sinne päästään underlayn kautta, ei sen päättämän tunnelin kautta.

Mitä istunto on jo asentanut

Ennen kuin kirjoitat omaa taulua, tulosta mitä linkin mukana tuli. Tuettu PPP-integraatio asentaa yleensä istunnon asetuksessa laiteen reitin ja peer-reitin, ja nämä kaksi merkintää koodaavat jo oikean lukutavan.

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

Laiteen reitti kuten 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ei kanna yhdyskäytävää, koska liitäntä itse on polku. Reitti, joka nimeää peerin via:llä, on toinen objekti, jolla on toinen elinikä, ja se katoaa, kun istunto katkeaa. Jomman kumman muodon kopioiminen pysyvään tauluun tarkistamatta, miten se asennetaan uudelleen, on tavallinen syy sille, että toimiva tunneli menettää reittinsä uudelleenyhdistämisen jälkeen.

Vertaa kahta listausta sen sijaan, että luottaisit muistiin. Jos peer-reitti on main mutta lisätaulusi on tyhjä, opit jotain, mitä osoiterivi ei koskaan kertonut sinulle.

Sääntö ja taulu ovat erillisiä päätöksiä

Taulun valitseminen ja sen täyttäminen ovat riippumattomia vaiheita, ja vertailu on tässä tärkeä, koska nämä kaksi sekoitetaan usein vianetsinnässä. Sääntö, joka lähettää merkittyä liikennettä tauluun 100, ei tee mitään, jos taulussa 100 ei ole vastaavaa reittiä, ja hyvin täytetty taulu on saavuttamaton, jos mikään sääntö ei osoita siihen.

Puolet oletusreitistä ei ole oletusreitti. Yksi 0.0.0.0/1 kattaa IPv4-avaruuden alapuolen, joten politiikka, joka aikoo napata kaiken, tarvitsee myös vastaavan 128.0.0.0/1:n tai aidon default:n. Toimivan kokoonpanon lukeminen ja toisen puoliskon kopioiminen on tapa, jolla ihmiset päätyvät reitityssilmukkaan, joka katkeaa vain tietyillä kohteilla.

Jätä tarkoitukselliset poikkeukset osoitteille, joiden on pysyttävä LAN-verkossa, ja päätä, mitä tapahtuu, kun haku ei löydä valitusta taulusta mitään. Selkeä varareitti on helpompi perustella kuin tyhjä taulu, joka palauttaa saavuttamattoman tuloksen ja saa sovelluksen näyttämään rikkinäiseltä eikä väärin reititetyltä.

Esitä haulle kysymys, jonka sovelluksesi esittää

ip route get ratkaisee polun; ip route show luettelee tallennetut merkinnät, ja molemmat voivat olla eri mieltä ilman, että kumpikaan on väärässä. Sisällytä lähdekonteksti, koska lähdeperusteiset säännöt täsmäävät vain, kun haku kuljettaa lähdettä.

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

Ensimmäinen komento esittää kysymyksen isännän puolelta. Toinen lisää tulevan liitännän, mikä on lähempänä sitä, mitä välitetty liikenne kokee, ja vastaus osoittaa usein toiseen tauluun. Kumpikaan kohde ei ole elävä testipalvelu; 198.51.100.23 on dokumentaatio-osoite, joten korvaa se isännällä, jota sinulla on lupa koetella.

Jopa oikea haku todistaa vain, että polku valittiin. Se ei kerro, hyväksyykö toinen puoli liikenteen vai voiko vastaus palata samalla päättelyllä.

Missä vertailu kääntyy

Isännän liikenne ja välitetty liikenne eivät vain tee erilaisia hakuja; paluumatkalla ne kohtaavat erilaisia suodattimia. Linux soveltaa käänteisen polun validointia käyttäen tiukempaa kaikkien liitäntöjen ja vastaanottavan liitännän asetuksista, joten yhden liitännän arvon muuttaminen ei välttämättä näy mitenkään. Merkkiin perustuva reititys lisää suhteen src_valid_mark, jossa merkin on täsmättävä, jotta lähde katsotaan kelvolliseksi.

Jos vastaukset katoavat, kun lähtevä reititys näyttää oikealta, lue voimassa olevat arvot ennen niihin koskemista ja muuta niitä vain ilmoitetusta politiikkasyystä.

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

Valitse kahden mallin välillä todisteiden perusteella: jos sovellus sitoutuu PPP-osoitteeseen, lähdesääntö ja peer-reitin sisältävä taulu riittävät. Jos laatikko välittää liikennettä takanaan olevalle LAN-verkolle, tarvitset myös, että tuleva konteksti ja paluupolku täsmäävät. Kun ne eivät täsmää, korjaa reitin omistajuus sen sijaan, että löysäisit validoinnin koko koneelle.