L2TP, GRE eða IPsec: hvaða lag á að bera setuna?

Þegar L2TP, GRE og IPsec lenda í sama hönnunarskjali flækjast tvær spurningar: hvaða setu er ég að bera, og hvaða lag verndar hana? Ef fyrri spurningin er röng helst allt sem á eftir kemur innbyrðis samkvæmt en leysir rangt vandamál — beint yfirlag byggt þar sem notendur þurftu að hringja inn, eða innhringimiðstöð sem stendur í stað síðu-til-síðu gáttar. Vinnublaðið hér að neðan þvingar þessa aðgreiningu áður en nokkur skráir sig inn á tæki. Fylltu það út í réttri röð og hver lína verður eitthvað sem þú getur prófað eitt og sér.

Byrjaðu á setunni, ekki á prótókóllistanum

Fjartengdur notandi með PPP-setu og beint yfirlag milli tveggja gátta eru ólík nettengsl, jafnvel þótt bæði endi innvafin í IPsec. Hið fyrra lýkur tengingu fyrir hvern notanda og þarf úthlutun vistfanga, auðkenningu einstaklings eða tækis og stefnu sem tilgreinir hvaða innri net sá notandi má ná til. Hið síðara sendir pakka milli staða sem enginn hringir inn í.

Skrifaðu eina setningu sem tilgreinir hvort þú ert að byggja, og lestu hana síðan aftur eins og þú værir sá sem á að stýra henni. Ef setningin þarf orðið „og“ ert þú að byggja bæði, og vinnublaðið þarf tvo dálka í stað eins málamiðlundardálks sem þjónar hvoru um hálft. Ef hún tilgreinir notanda en engan vistfangapott, eða forskeyti en enga sendingarstefnu, er setningin enn ófullkomin. Orðalagið hljómar skrifræðislegt, en það er ódýrasti staðurinn til að grípa hönnun sem annars uppgötvast með miðasölu á þjónustuborði.

Gefðu hverju lagi nákvæmlega eitt verk

L2TPv2 ber PPP-setur milli tveggja endapunkta sinna. PPP stýrir tengisamningum og, þegar samið er, auðkenningu notandans; L2TP bætir engri dulritun við, svo óvarið L2TP-þjónn innleiðir ekkert af öryggissambandi IPsec og á aðeins heima í tengingu sem þú treystir nú þegar.

GRE er umvafningur milli tveggja vistfanga. Það ber pakka nettengingarlagsins yfir röklegt yfirlag og býður, eitt og sér, hvorki trúnað né auðkennda sjálfsmynd jafningja. Það er ekki galli: hausnum var hannaður einfaldur svo hann haldist ódýr í vinnslu á sendingarvélbúnaði. Afleiðingin er sú að GRE svarar aðeins hvernig færa eigi þennan pakka milli tveggja vistfanga og engu öðru, og það er einmitt spurningin sem þú ættir að spyrja það.

Þá stendur IPsec eftir sem lagið sem velur umferð, auðkennir jafningja og dulkóðar það sem því var sagt að vernda. Hvaða umferð það verndar er stillingarákvörðun sem verður að passa við umvafninguna sem endapunktarnir framleiða í raun, því stefna sem skrifuð er fyrir ytra vistfang GRE hagar sér öðruvísi en sú sem skrifuð er fyrir innri forskeytin. GRE-forskriftin heldur hleðslu, GRE-haus og ytri afhendingarprótókoll greinilega aðskildum, og stefnan þín þarf sömu aðgreiningu.

Skrifaðu pökkaleiðina áður en stillingarnar koma

Taktu einn pakka og skráðu hvern haus sem bætist við, í þeirri röð sem hann bætist við, og nefndu tækið sem bætir honum við. Fyrir innhringinotanda er það venjulega PPP inni í L2TP inni í IPsec; fyrir yfirlag staðar er það innri IP-pakkinn inni í GRE inni í IPsec. Ef tvö tæki bæta við sama haus hefur þú lykkju eða tvífalda göng, og engin stefnuvinna lagar það.

Sami listi ræður MTU, því nothæf innri stærð er mæld leiðar-MTU að frádregnum hausunum sem þú taldir upp og engu öðru. Ekki afrita tölu úr vefspjallsfærslu: leggðu saman ytri IP-, UDP- og ESP-yfirbyrði, svo GRE eða L2TP, svo PPP þar sem við á, og dragðu frá leiðar-MTU sem þú mældir í raun. Einkenni sem koma aðeins fram á stórum flutningum, eða setur sem koma upp og deyja svo á fyrsta stóra svari, rekja sig venjulega til þess að sú samlagning var gerð eftir ágiskun.

Athugaðu hvert lag fyrir sig, utan frá og inn

Keyrðu athuganirnar í röð og stöðvaðu við þá fyrstu sem bregst. Hver lína svarar annarri spurningu, svo bilun bendir á einn dálk vinnublaðsins í stað þess að segja þér að göngin séu brotin.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Á Cisco-kassa er samsvarandi háð hlutverki, og nákvæm setningagerð fer eftir vettvangi og útgáfu: show crypto session fyrir IPsec-jafningja, viðmótsteljarar fyrir GRE- eða gönguviðmót, og VPDN- eða PPP-staðfesting fyrir innhringihlutverkið. Skipanalisti sem lýkur PPP sannar ekkert um GRE-stuðning, og vinnandi GRE-viðmót sannar ekkert um PPP-þjónustuna, svo staðfestu hlutverkið sem þú stilltir í raun frekar en það sem er á skýringarmyndinni.

Skráðu hvert úttak við hlið þeirrar línu vinnublaðsins sem það tilheyrir. Athugasemdir sem skrifaðar eru á meðan bilunin er virk eru verðmætari en grunnnet sem endurteiknað er síðar eftir minni.

Raðaðu niðurrifinu og staðfestu svo aftur

Niðurrif gengur í öfuga átt af ástæðu: taktu verndaða umferð út úr IPsec-stefnunni áður en þú fjarlægir umvafninguna sem hún var skrifuð fyrir, annars heldur stefnan áfram að benda á viðmót sem er ekki lengur til og næsta stillingarhleðsla bregst einhvers staðar sem virðist ótengt. Á Linux þýðir það að eyða stöðu- og stefnufærslum áður en gönguviðmótið fer; á beini, að fjarlægja crypto-kortið eða prófílafærsluna áður en göngin fara.

Eftir endurbyggingu skaltu endurtaka fjórar samþykktarathuganir einar og sér: ytri náanleika, komið IPsec-samband, komna PPP-setu þar sem hönnunin felur í sér eina, og innri sendingu á raunverulegt áfangavistfang. Eitt grænt ljós er ekki sönnun fyrir hinum þremur, og það bil er bilunin sem lifir lengst í framleiðslu — göng sem eru uppi, dulkóðuð og senda ekkert því innri leiðinni var aldrei bætt við.

Haltu útfylltu vinnublaðinu við hlið tækisstillingarinnar. Hver dálkur sem þú getur ekki fyllt út er lag án úthlutaðs verks, og lag án úthlutaðs verks er venjulega lag sem á ekki að vera í staflanum.