L2TP, GRE o IPsec: aling layer ang dapat magdala ng session?
Nagdadala ang L2TP ng mga PPP session, ang GRE ng mga routed packet, pinoprotektahan ng IPsec ang piniling trapiko. Bigyan ang bawat layer ng isang tungkulin, pagkatapos i-verify ang bawat isa nang hiwalay.
Dalawang tanong ang nagkakabuhol sa tuwing L2TP, GRE at IPsec ay mapupunta sa isang design note: aling session ang dinadala ko, at aling layer ang nagpoprotekta rito? Kung mali ang una, nananatiling panloob na pare-pareho ang lahat sa ibaba pero maling problema ang nilulutas — isang routed overlay na itinayo kung saan kailangan ng mga user na mag-dial in, o isang dial-in concentrator na nakatayo kapalit ng site-to-site gateway. Pinipilit ng worksheet sa ibaba ang pagkakaibang iyon bago mag-log in ang sinuman sa isang device. Sagutan ito nang sunod-sunod at ang bawat linya ay magiging bagay na maaari mong subukan nang mag-isa.
Magsimula sa session, hindi sa listahan ng protocol
Ang isang remote na user na may PPP session at isang routed overlay sa pagitan ng dalawang gateway ay dalawang magkaibang ugnayan sa network, kahit pareho silang mauwi sa nakabalot sa IPsec. Ang una ay nagtatapos ng link para sa bawat user at nangangailangan ng paglalaan ng address, pagpapatunay ng tao o device, at patakarang nagbabanggit kung aling panloob na network ang maaaring maabot ng user na iyon. Ang pangalawa ay nagpapasa ng packet sa pagitan ng mga site na walang nagda-dial in.
Sumulat ng isang pangungusap na nagbabanggit kung alin sa dalawa ang itinatayo mo, pagkatapos basahin itong muli na parang ikaw ang taong kailangang magpatakbo nito. Kung kailangan ng pangungusap ang salitang «at», itinatayo mo ang pareho, at kailangan ng worksheet ng dalawang column sa halip na isang compromise column na kalahating naglilingkod sa bawat isa. Kung binabanggit nito ang isang user pero walang address pool, o isang prefix pero walang patakaran sa pagpapasa, hindi pa kumpleto ang pangungusap. Burokratiko ang dating ng pananalita, pero ito ang pinakamurang lugar para mahuli ang isang design na kung hindi ay matutuklasan ng ticket sa help desk.
Bigyan ang bawat layer ng eksaktong isang tungkulin
Nagdadala ang L2TPv2 ng mga PPP session sa pagitan ng dalawang endpoint nito. Pinapatakbo ng PPP ang negosasyon sa link at, kapag napagkasunduan ito, ang pagpapatunay ng user; Walang idinadagdag na kriptograpiya ang L2TP, kaya ang hubad na L2TP daemon ay walang ipinapatupad na bahagi ng ugnayang panseguridad ng IPsec at nabibilang lamang sa loob ng link na pinagkakatiwalaan mo na.
Ang GRE ay isang encapsulation sa pagitan ng dalawang address. Nagdadala ito ng packet ng network layer sa isang lohikal na overlay at, nang mag-isa, ay hindi nag-aalok ng pagiging kompidensyal o ng beripikadong pagkakakilanlan ng kapareha. Hindi ito depekto: dinisenyo ang header na simple para manatiling mura ang pagproseso sa hardware ng pagpapasa. Ang bunga ay sinasagot ng GRE ang tanong kung paano ililipat ang packet na ito sa pagitan ng dalawang address at wala nang iba pa, at iyon ang eksaktong tanong na dapat mong itanong dito.
Nananatili ang IPsec bilang layer na pumipili ng trapiko, nagpapatunay sa mga kapareha at nag-e-encrypt ng sinabing protektahan nito. Aling trapiko ang pinoprotektahan nito ay desisyon sa configuration na dapat tumugma sa encapsulation na aktuwal na ginagawa ng mga endpoint, dahil ang patakarang isinulat para sa panlabas na address ng GRE ay kumikilos nang iba kaysa sa isinulat para sa mga panloob na prefix. Ang espesipikasyon ng GRE ay tahasang naghihiwalay ng payload, GRE header at panlabas na protocol ng paghahatid, at kailangan din ng patakaran mo ng ganoong paghihiwalay.
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
Isulat ang landas ng packet bago ang configuration
Kumuha ng isang packet at ilista ang bawat header na naidaragdag, sa pagkakasunod-sunod ng pagdaragdag, at banggitin ang device na nagdaragdag nito. Para sa user na nagda-dial in, karaniwan itong PPP sa loob ng L2TP sa loob ng IPsec; para sa overlay ng site, ito ang panloob na IP packet sa loob ng GRE sa loob ng IPsec. Kung dalawang device ang nagdaragdag ng parehong header, mayroon kang loop o doble ang tunnel, at walang pag-edit ng patakaran ang makakapag-ayos nito.
Ang parehong listahan ang nagtatakda ng MTU, dahil ang magagamit na panloob na sukat ay ang sinukat na MTU ng landas na binawasan ng mga header na kaaayos mo pa lang at wala nang iba. Huwag kopyahin ang numero mula sa post sa forum: pagsamahin ang overhead ng panlabas na IP, UDP at ESP, pagkatapos GRE o L2TP, pagkatapos PPP kung naaangkop, at ibawas sa MTU ng landas na aktuwal mong sinukat. Ang mga sintomas na lumilitaw lamang sa malalaking paglilipat, o mga session na naitatayo at pagkatapos ay namamatay sa unang malaking tugon, ay kadalasang bumabalik sa paggawa ng pagsasamang iyon nang hula lang.
Suriin ang bawat layer nang hiwalay, mula labas papasok
Patakbuhin ang mga pagsusuri nang sunod-sunod at huminto sa unang nabigo. Sumasagot ang bawat linya sa magkaibang tanong, kaya ang pagkabigo ay tumutukoy sa isang column ng worksheet sa halip na sabihing sira ang tunnel.
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?Sa isang Cisco box, ang katumbas ay nakadepende sa role, at ang eksaktong sintaks ay nakadepende sa platform at release: show crypto session para sa mga kaparehang IPsec, mga counter ng interface para sa GRE o tunnel interface, at ang beripikasyon ng VPDN o PPP para sa role ng dial-in. Ang isang set ng command na nagtatapos ng PPP ay walang pinatutunayan tungkol sa suporta sa GRE, at ang gumaganang GRE interface ay walang pinatutunayan tungkol sa serbisyong PPP, kaya i-verify ang role na aktuwal mong na-configure at hindi ang nasa diagram.
Itala ang bawat output sa tabi ng linyang worksheet na kinabibilangan nito. Ang mga tala na kinuha habang buhay ang sira ay mas mahalaga kaysa sa topolohiyang muling iginuhit mamaya mula sa alaala.
Isaayos ang pagkakasunod-sunod ng pagtatanggal, pagkatapos muling i-verify
Ang pagtatanggal ay tumatakbo nang baligtad dahil sa isang dahilan: alisin ang protektadong trapiko sa patakarang IPsec bago mo tanggalin ang encapsulation na isinulatan nito, kung hindi ay patuloy na tumuturo ang patakaran sa isang interface na wala na at ang susunod na paglo-load ng configuration ay nabibigo sa lugar na mukhang walang kaugnayan. Sa Linux, ang ibig sabihin nito ay burahin ang mga entry ng estado at patakaran bago ang tunnel interface; sa router, alisin ang crypto map o entry ng profile bago ang tunnel.
Pagkatapos ng muling pagtatayo, ulitin ang apat na obserbasyon sa pagtanggap nang isa-isa: panlabas na maabot, naitayong IPsec association, naitayong PPP session kung saan kasama ito sa design, at panloob na pagpapasa sa tunay na address ng destinasyon. Ang isang berdeng ilaw ay hindi ebidensiya para sa tatlo pa, at ang agwat na iyon ang sira na pinakamatagal na nabubuhay sa produksiyon — isang tunnel na nakaupo, naka-encrypt, at walang ipinapasa dahil kailanman hindi naidagdag ang panloob na ruta.
Itabi ang nakasagutang worksheet sa tabi ng configuration ng device. Anumang column na hindi mo masagutan ay layer na walang nakatalagang tungkulin, at ang layer na walang tungkulin ay karaniwang layer na hindi dapat naroroon sa stack.