L2TP, GRE of IPsec: hokker laach moat de sesje drage?

Elke kear as L2TP, GRE en IPsec yn deselde ûntwerpnoot bedelje, reitsje twa fragen trochinoar: hokker sesje drage ik, en hokker laach beskermet dy? Krijst de earste ferkeard, dan bliuwt alles derûnder yntern konsekwint wylst it it ferkearde probleem oplost — in rûte oerlaach boud dêr't brûkers har oanmelde moasten, of in oanmeldkonsintrator yn plak fan in side-oan-side-poarte. It ûnderste wurkblêd twingt dy ûnderskied foarôf, ear't immen op in apparaat ynlocht. Folje it op folchoarder yn en elke rigel wurdt eat datsto sels testen kinst.

Begjin by de sesje, net by de protokollist

In ôfstânsbrûker mei in PPP-sesje en in rûte oerlaach tusken twa poarten binne ferskillende netwurkrelaasjes, sels as beide úteinlik yn IPsec ferpakt wurde. De earste beëiniget in keppeling per brûker en hat adresútwizing, autentikaasje fan in persoan of apparaat, en in belied nedich dat neamt hokker ynterne netwurken dy brûker berikke mei. De twadde ferstjoert pakketten tusken siden dêr't nimmen him oanmeldet.

Skriuw ien sin dy't neamt hokker fan de twaasto bouwst, en lês dy dan werom as wieasto de persoan dy't it betsjinje moat. As de sin it wurd «en» nedich hat, bousto beide, en it wurkblêd hat twa kolommen nedich ynstee fan ien kompromiskolom dy't elk heal betsjinnet. As it in brûker neamt mar gjin adrespoel, of in prefiks mar gjin trochstjoerbelied, dan is de sin noch altyd ûnfolslein. De bewurding klinkt burokratysk, mar it is it goedkeapste plak om in ûntwerp te fangen dat oars troch in helpdeskticket ûntdutsen wurde soe.

Jou elke laach krekt ien taak

L2TPv2 draacht PPP-sesjes tusken syn twa einpunten. PPP fiert de keppelingûnderhanneling en, as dy plakfynt, de brûkersautentikaasje; L2TP foeget gjin kryptografy ta, dat in keale L2TP-daemon ymplemintearret gjin inkeld part fan 'e IPsec-feiligensrelaasje en heart allinnich binnen in keppeling dy'tsto al fertroust.

GRE is in ynkapseling tusken twa adressen. It draacht pakketten fan 'e netwurklaach oer in logyske oerlaach en biedt op himsels noch fertroulikens noch in autentisearre partneridentiteit. Dat is gjin defekt: de kop is ienfâldich ûntwurpen sadat it goedkeap bliuwt om op trochstjoerhardware te ferwurkjen. It gefolch is dat GRE antwurdet op «hoe ferpleats ik dit pakket tusken twa adressen» en op neat oars, en krekt dat is de fraach dy'tsto it stelle moast.

Dat lit IPsec oer as de laach dy't ferkear selektearret, de partners autentisearret en fersifert wat it te beskermjen krige. Hokker ferkear it beskermet is in konfiguraasjebeslút dat oerienkomme moat mei de ynkapseling dy't de einpunten eins generearje, om't in belied skreaun foar it bûtenadres fan GRE oars gedraacht as ien skreaun foar de ynterne prefiksen. De GRE-spesifikaasje hâldt nutslast, GRE-kop en bûtenste ôfleveringsprotokol sichtber apart, en dyn belied hat deselde skieding nedich.

Skriuw it pakketpaad foar de konfiguraasje

Nim ien pakket en list elke kop op dy't tafoege wurdt, yn 'e folchoarder fan tafoegjen, en neam it apparaat dat it docht. Foar in oanmeldbrûker is dat meast PPP yn L2TP yn IPsec; foar in side-oerlaach is it it ynterne IP-pakket yn GRE yn IPsec. As twa apparaten deselde kop tafoegje, hasto in lus of in dûbele tunnel, en gjin inkel beliedsbewurking sil dat oplosse.

Deselde list beslist ek de MTU, om't de brûkbere ynterne grutte de metten paad-MTU is minus de koppen dy'tsto krekt opliste, en neat oars. Kopiearje gjin getal fan in forumberjocht: tel de bûtenste IP-, UDP- en ESP-oerhead byinoar, dan GRE of L2TP, dan PPP wêr't it jildt, en lûk dat ôf fan 'e paad-MTU dy'tsto eins metten hast. Symptomen dy't allinnich by grutte oerdrachten ferskine, of sesjes dy't opkomme en dan stjerre by it earste grutte antwurd, liede meastentiids werom nei dy optelling dy't op 'e gis dien waard.

Kontrolearje elke laach apart, fan bûten nei binnen

Rin de kontrôles op folchoarder en stop by de earste dy't misgiet. Elke rigel antwurdet in oare fraach, dat in misser wiist nei ien kolom fan it wurkblêd ynstee dat it seit dat de tunnel stikken is.

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?

Op in Cisco-apparaat hinget it ekwivalint fan 'e rol ôf, en de krekte syntaksis fan it platfoarm en de ferzje: show crypto session foar de IPsec-partners, ynterface-tellers foar de GRE of tunnel-ynterface, en de VPDN- of PPP-ferifikaasje foar de oanmeldrol. In kommandoset dat PPP beëiniget, bewiist neat oer GRE-stipe, en in wurkjende GRE-ynterface bewiist neat oer de PPP-tsjinst, dat ferifiearje de rol dy'tsto eins konfigurearre hast, net dy op it diagram.

Skriuw elke útfier njonken de wurkblêdrigel dêr't er by heart. Oantekeningen makke wylst de stoaring libbet, binne mear wurdich as in topology dy't letter út 't ûnthâld wei opnij tekene wurdt.

Oarderje de ôfbraak, en ferifiearje dan opnij

De ôfbraak rint efterstfoar om in reden: helje it beskerme ferkear út it IPsec-belied foar'tsto de ynkapseling fuorthelje dêr't it foar skreaun wie, oars bliuwt it belied wizen nei in ynterface dat net mear bestiet en misgiet de folgjende konfiguraasjelading earne dat der net by heart. Op Linux betsjut dat it fuortheljen fan 'e steat- en beliedsrecords foar de tunnel-ynterface; op in router it fuortheljen fan 'e crypto map of profilynstjoer foar de tunnel.

Nei de weropbou, werhelje de fjouwer akseptaasje-observaasjes ien foar ien: bûtenberikberens, in fêstige IPsec-assosjaasje, in fêstige PPP-sesje wêr't it ûntwerp ien befettet, en ynterne trochstjoering nei in echt bestimmingsadres. Ien grien ljocht is gjin bewiis foar de oare trije, en krekt dy kleau is de stoaring dy't it langst oerlibbet yn produksje — in tunnel dy't oan is, fersifere, en neat trochstjoert om't de ynterne rûte nea tafoege is.

Hâld it ynfolle wurkblêd njonken de apparaatkonfiguraasje. Elke kolom dy'tsto net folje kinst is in laach sûnder tawiisde taak, en in laach sûnder tawiisde taak heart meastentiids net yn 'e stack.