Leiðatöflu á móti raunverulegri uppflettingu: hvert fer VPN-umferð

Útprentun leiðatöflu er gagnslausasta greiningin við VPN-villuleit og sú sem oftast er límd inn. Fjörutíu línur af forskeytum segja þér hvað vélin gæti gert, ekki hvað hún gerði fyrir beiðnina sem mistókst. Aðferðin sem þú vilt í raun er uppflettingin: með þennan uppruna og þennan áfangastað, hvaða regla passaði, hvaða tafla var skoðuð og hvaða tengi og næsta hopp komu út. Byrjaðu á einum áfangastað og einum uppruna, lestu svo töfluna með þá spurningu í höndunum, og sama úttakið verður sönnun í stað hávaða.

Tafla er safn frambjóðenda, ekki ákvörðun

Hver færsla lýsir forskeyti og hvað eigi að gera við umferð sem passar við það: senda hana á tengi, afhenda næsta hoppi eða henda henni. Ekkert í þeim lista er raðað eftir ásetningi, og færslan sem virðist sértækust fyrir manneskju er ekki alltaf sú sem kjarninn velur, því valið fylgir lengstu forskeytasamsvörun og, meðal jafnra forskeyta, mælikvarðanum.

Þannig að fyrsta skrefið er að spyrja kjarnann í stað þess að lesa listann. Uppflettiskipunin svarar fyrir áfangastað, og með upprunarökli svarar hún fyrir nákvæma parið sem framsend eða bundin tenging myndi nota:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Hvert hnit hér að ofan er skjölunardæmi. Málið er lögun svarsins: tengi, valið upprunahnet, gátt og taflan sem færslan kom úr. Ef það úttak passar ekki við tengið sem þú bjóst við hefur þú staðsett vandann með einni skipun, og engin lestur fullu töflunnar hefði sagt þér hvaða frambjóðandi vann.

Uppflettingin fer fyrst í gegnum reglur, svo töflur

Á Linux er ákvörðunin í tveimur þrepum. Stefnureglur eru metnar í forgangsröð, og fyrsta reglan sem passar nefnir töflu til að skoða; sú tafla gerir svo lengstu forskeytasamsvörunina. Regla getur passað við uppruna, áfangastað, eldveggsmerki, tengi eða samsetningu, og þess vegna getur útprentun aðaltöflunnar verið algerlega nákvæm og algerlega óviðkomandi fyrir pakkann sem þú rannsakar.

ip rule show
ip route show table all | head -40
ip route show table 100

Ef regla sendir umferð frá VPN-safninu þínu í töflu 100, þá er tafla 100 sú sem skiptir máli, og aðaltaflan er tálbeita. Þetta er líka aðferðin að baki upprunatengdri leiðastýringu á beini: sami áfangastaður getur haft tvö mismunandi svör eftir því hvaðan pakkinn kom, og aðeins uppflettingin með upprunarökli sýnir hvort á við.

IPv6 hefur eigin reglur og töflur. Hönnun sem keyrir báðar fjölskyldurnar þarf báðar uppflettingarnar, og virkt IPv4 svar segir ekkert um v6 leiðina sem tvístafla biðlari kann að kjósa.

Hvað VPN-biðlarinn setur upp

Biðlarar skipta venjulega ekki út sjálfgefinni leið, því það myndi brjóta eigin ytri leið tunnilsins. Þeir setja upp eitthvað sértækara sem vinnur á forskeytalengd: par hálfsjálfgefna leiða sem ná yfir 0.0.0.0/1 og 128.0.0.0/1 er klassíska brellan, þar sem báðar eru lengri forskeyti en 0.0.0.0/0 og saman ná þær yfir allt rýmið. Aðrir setja upp tiltekin einkaforskeyti auk stefnureglu, og sumir bæta við merki svo aðeins valin umferð sé gripin.

Þess vegna er "VPN-ið breytti ekki sjálfgefinni leiðinni minni" ekki sönnun um bilun. Athugaðu hvað það bætti reyndar við, og hvort áfangastaðurinn sem um ræðir falli innan þeirra forskeyta:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Tvær hálfleiðir er auðvelt að missa af í útprentun því þær líta ekki út eins og sjálfgefin leið. Split-tunnel uppsetning sem gleymdi að hafa forskeyti með framleiðir nákvæmlega þau einkenni sem þú eltir: forritið sem ætti að nota tunnilinn leysir og tengist staðbundið í staðinn. Berðu saman uppsett forskeyti við áfangastaðina sem notandinn þarf í raun, ekki við hnitan sem þú prófaðir fyrir tilviljun. Split-tunnel listi sem nær yfir skráaþjóninn en ekki leysinn hans framleiðir tengingu sem leysist í opinbert hnit og mistekst svo við auðkenningu, sem lítur út eins og lykilorðsvandamál og er leiðarvandamál.

Ytri leiðin verður líka að lifa af

Tunnillinn er sjálfur umferð. Pakkarnir sem bera umbúðaða hleðsluna fara á hnit jafningjans um líkamlega tengið, og þá leið má ekki leiðast aftur inn í tunnilinn. Þegar það gerist færðu einkennandi bilun þar sem tunnillinn rís og hættir svo að flytja umferð, því flutningur tunnilsins er nú inni í tunnilnum.

Athugaðu hnit jafningsins eins og þú athugaðir innri áfangastaðinn, og staðfestu að það leysist í líkamlega tengið en ekki tunnilinn:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Endurkvæm leið, stefnuregla sem grípur jafningjann eða sjálfgefin leið sem fulltunnel-biðlari skipti út eru algengu þrjár orsakirnar. Allar þrjár sjást í ytri uppflettingunni, og engin þeirra sést í útprentun aðaltöflunnar sem tekin er eftir á.

Hvað leiðarúttakið getur ekki sagt þér

Rétt uppfletting þýðir að kjarninn myndi senda pakkann á skynsamlegan stað. Það þýðir ekki að eldveggurinn leyfi hann, IPsec-stefnan nái yfir hann, NAT-reglan þýði hann eða hinum megin sé til bakleið. Hvert þeirra er seinna þrep, og athugasemdir strongSwan um framsendingu lýsa keðjunni sem pakki verður að fara í gegnum á báðum endum.

Það tekur líka ekki tillit til bindingar á forritastigi. Ferli getur bundið sig við tengi, sett merki eða notað eigin leysi og tengst með nafni sem leysist öðruvísi en það sem þú prófaðir. Þegar uppflettingin er rétt og tengingin mistekst samt, er næsta spurning hvaða ferli myndar hana og hvort það ferli sjái sömu töflu og þú.

Haltu greiningunni því í röð: nefndu áfangastaðinn og upprunann, keyrðu uppflettinguna, lestu aðeins töfluna og regluna sem uppflettingin nefndi, og prófaðu svo næsta þrep. Sú röð heldur leiðarrannsókn innan mínútna og skilur eftir skrá sem aðrir geta fylgt, sem límd tafla gerir aldrei.