PPP-peer-vistfang á móti VPN-endapunkti: hvað á heima í via

Ein lína á PPP-tengi ræður flestum deilum um leiðsögn í VPN-kassa: innra vistfangið og peer-ið sem prentað er við hliðina. Lestu þetta par sem pítið undirnet og þú munt leita að gátt sem er ekki til. Lestu það sem tvo enda eins tengls og næsta hopp verður augljóst. Samanburðurinn hér stendur milli þessara tveggja lestra, því hver tafla sem þú byggir síðar erfir þá sem þú valdir. Ekkert um ytra VPN-endapunktinn er ákveðið af hvorugum þeirra.

Tvær lestrar á einni tengislínu

Taktu lotu þar sem tengið tilkynnir inet 10.64.3.9 peer 10.64.3.1/32. Undirnetslesturinn meðhöndlar 10.64.3.9 sem eina hýsingu á /32-eyju og leitar síðan að beini til að ná einhverju handan hennar. Þar sem eina annað vistfangið á línunni er peer-ið, endar sá lestur á að stinga upp á 10.64.3.9 sjálfu sem gátt, sem er hringrök.

Endapunktslesturinn er hinn skjalfesti. Á punkt-til-punkt tengi nefnir peer fjarlæga enda þess eins tengls, svo 10.64.3.1 er nothæfa næsta hoppið og 10.64.3.9 er alltaf aðeins upprunavistfang.

Sá munur stýrir hvað má koma fyrir í via. Að skrifa staðbundna vistfangið þar framleiðir leið sem kjarninn getur ekki leyst upp í nágranna, svo færslan mistekst í staðfestingunni eða gleypir umferð á meðan hún lítur fullkomlega heil út í lista. Peer-ið virkar því það er raunverulegur áfangastaður á tenglinu. Báðir lestrarnir eru sammála um ytra VPN-endapunktinn, sem er algjörlega sérstök sjálfsmynd: hann er náð í gegnum undirlagið, ekki í gegnum göngin sem hann endar.

Hvað lotan hefur þegar sett upp

Áður en þú skrifar eigin töflu skaltu prenta það sem fylgdi tenglinu. Stuðningur PPP-samþætting setur venjulega upp tækjaleið og peer-leið við uppsetningu lotunnar, og þessar tvær færslur kóða þegar rétta lesturinn.

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

Tækjaleið eins og 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ber enga gátt því tengið sjálft er leiðin. Leið sem nefnir peer-ið með via er annar hlutur með aðra líftíma, og hún hverfur þegar lotan dettur. Að afrita aðra hvorja myndina í varanlega töflu án þess að athuga hvernig hún er sett upp aftur er venjulega ástæðan fyrir því að virk göng missa leiðina eftir endurtengingu.

Berðu saman listana tvo í stað þess að treysta minninu. Ef peer-leiðin er til í main en aukataflan þín er tóm, hefurðu lært eitthvað sem vistfangslínan sagði þér aldrei.

Regla og tafla eru aðskildar ákvarðanir

Að velja töflu og að fylla hana eru óháð skref, og samanburðurinn skiptir máli hér því oft er ruglað saman þessu tvennu við kembiforritun. Regla sem sendir merktra umferð í töflu 100 gerir ekkert ef tafla 100 hefur enga samsvarandi leið, og vel fyllt tafla er óaðgengileg ef engin regla bendir á hana.

Hálf sjálfgefin leið er ekki sjálfgefin leið. Ein 0.0.0.0/1 nær yfir neðri helming IPv4-rýmisins, svo stefna sem ætlar að grípa allt þarf einnig samsvarandi 128.0.0.0/1, eða alvöru default. Að lesa virka uppsetningu og afrita annan helminginn er hvernig fólk endar með leiðsagnarlykkju sem brotnar bara á ákveðna áfangastaði.

Leyfðu viljandi undantekningar fyrir vistfangin sem verða að vera á LAN-inu, og ákveddu hvað gerist þegar uppflettingin finnur ekkert í völdu töflunni. Skýr varaleið er auðveldari að rökræða en tóm tafla, sem skilar óaðgengilegri niðurstöðu og lætur forritið líta út fyrir að vera bilað frekar en rangt beint.

Spurðu uppflettinguna sömu spurningar og forritið þitt

ip route get leysir upp leið; ip route show listar geymdar færslur, og þau tvö geta verið ósammála án þess að annað sé rangt. Hafðu upprunasamhengið með, því reglur byggðar á uppruna passa aðeins þegar uppflettingin ber uppruna.

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

Fyrsta skipunin spyr spurningarinnar frá hýsingunni. Önnur bætir við inngöngutengi, sem er nær því sem áframmiðuð umferð upplifir, og svarið bendir oft á aðra töflu. Hvorugur áfangastaðurinn er lifandi prófunarþjónusta; 198.51.100.23 er skjalfestingarvistfang, svo skiptu því út fyrir hýsingu sem þú mátt rannsaka.

Jafnvel rétt uppfletting sannar aðeins að leið hafi verið valin. Hún segir ekkert um hvort hinum megin sé umferðin samþykkt eða hvort svarið geti snúið til baka með sömu röksemd.

Þar sem samanburðurinn veltur

Umferð frá hýsingu og áframmiðuð umferð taka ekki bara mismunandi uppflettingar; þær mæta mismunandi sím á leiðinni til baka. Linux beitir öfugleiðarstaðfestingu með þeirri ströngu stillingarinnar fyrir öll tengi og fyrir móttökutengið, svo breyting á gildi eins tengis getur haft engin sýnileg áhrif. Merkjabundin leiðsögn bætir við sambandinu src_valid_mark, þar sem merkið verður að passa til að uppruni teljist gildur.

Ef svör hverfa á meðan útleiðin lítur rétt út, lestu virku gildin áður en þú snertir þau, og breyttu þeim aðeins með tilgreindri stefnuástæðu.

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

Veldu milli hönnunanna tveggja á grundvelli sönnunar: ef forritið bindur sig við PPP-vistfangið er upprunaregla ásamt töflu með peer-leiðinni nóg. Ef kassinn miðlar áfram fyrir LAN fyrir aftan sig þarftu líka að inngöngusamhengið og afturleiðin séu sammála. Þegar þau eru það ekki skaltu laga eignarhald leiðarinnar í stað þess að slaka á staðfestingunni fyrir alla vélina.