L2TP, GRE vagy IPsec: melyik réteg vigye a munkamenetet?

Két kérdés gabalyodik össze, valahányszor az L2TP, a GRE és az IPsec ugyanabba a tervezési jegyzetbe kerül: melyik munkamenetet viszem, és melyik réteg védi? Ha az elsőre rosszul válaszolsz, minden további belsőleg konzisztens marad, miközben a rossz problémát oldod meg — irányított átfedés épül ott, ahol a felhasználóknak be kellett volna tárcsázniuk, vagy egy betárcsázós koncentrátor áll a telephelyek közötti átjáró helyett. Az alábbi munkalap ezt a megkülönböztetést kényszeríti ki, mielőtt bárki bejelentkezne egy eszközre. Töltsd ki sorban, és minden sor olyasmivé válik, amit külön is tesztelhetsz.

A munkamenetből indulj ki, ne a protokollok listájából

A PPP-munkamenetet tartó távoli felhasználó és a két átjáró közötti irányított átfedés különböző hálózati viszonyok, még akkor is, ha mindkettő végül IPsecbe csomagolódik. Az első felhasználónkénti kapcsolatot zár le, és címkiosztást, egy személy vagy eszköz hitelesítését, valamint olyan szabályzatot igényel, amely megnevezi, mely belső hálózatokat érheti el az a felhasználó. A második olyan telephelyek között továbbít csomagokat, amelyekre senki sem tárcsáz be.

Írj egy mondatot, amely megnevezi, melyiket építed a kettő közül, majd olvasd vissza úgy, mintha te lennél az, akinek üzemeltetnie kell. Ha a mondatnak kell az „és” szó, mindkettőt építed, és a munkalapnak két oszlop kell egyetlen kompromisszumos oszlop helyett, amely mindkettőt félig szolgálja. Ha megnevez egy felhasználót, de nincs címkészlet, vagy egy előtagot, de nincs továbbítási szabályzat, a mondat még hiányos. A megfogalmazás bürokratikusan hangzik, de ez a legolcsóbb hely elkapni egy tervet, amelyet különben egy ügyfélszolgálati jegy fedez fel.

Minden rétegnek pontosan egy feladatot adj

Az L2TPv2 PPP-munkameneteket visz a két végpontja között. A PPP végzi a kapcsolat egyeztetését, és amikor azt egyeztetik, a felhasználó hitelesítését; az L2TP nem ad hozzá semmilyen kriptográfiát, így egy csupasz L2TP-démon semmit sem valósít meg az IPsec biztonsági viszonyból, és csak egy már megbízható kapcsolat belsejébe tartozik.

A GRE egy becsomagolás két cím között. Hálózati rétegbeli csomagokat visz át egy logikai átfedésen, és önmagában sem bizalmasságot, sem hitelesített partnerazonosságot nem kínál. Ez nem hiba: a fejlécet szándékosan egyszerűre tervezték, hogy feldolgozása olcsó maradjon a továbbító hardveren. Ennek következménye, hogy a GRE a „hogyan mozgatom ezt a csomagot két cím között” kérdésre válaszol, és semmi másra — pontosan arra, amit kérdeznie kell tőle.

Így az IPsec marad az a réteg, amely kiválasztja a forgalmat, hitelesíti a partnereket, és titkosítja azt, amit védenie utasítottak. Hogy melyik forgalmat védi, konfigurációs döntés, amelynek egyeznie kell a végpontok által ténylegesen létrehozott becsomagolással, mert a GRE külső címére írt szabályzat másként viselkedik, mint a belső előtagokra írt. A GRE specifikáció láthatóan külön tartja a hasznos terhet, a GRE-fejlécet és a külső kézbesítési protokollt, és a szabályzatodnak ugyanerre az elkülönítésre van szüksége.

A konfiguráció előtt írd le a csomag útvonalát

Végy egy csomagot, és sorold fel minden hozzáadott fejlécet a hozzáadás sorrendjében, megnevezve az eszközt, amely hozzáadja. Betárcsázós felhasználónál ez általában PPP az L2TP-ben, az pedig IPsecben; telephelyi átfedésnél a belső IP-csomag a GRE-ben, a GRE pedig IPsecben. Ha két eszköz ugyanazt a fejlécet adja hozzá, hurok vagy duplikált alagút van, és semmilyen szabályzatmódosítás nem javítja meg.

Ugyanez a lista dönti el az MTU-t, mert a használható belső méret a mért útvonal-MTU mínusz az imént felsorolt fejlécek, és semmi más. Ne másolj számot fórumbejegyzésből: add össze a külső IP, az UDP és az ESP többletét, majd a GRE vagy L2TP, majd ahol érvényes, a PPP többletét, és vond ki a ténylegesen mért útvonal-MTU-ból. A csak nagy átvitelnél jelentkező tünetek, vagy a felépülő, majd az első nagy válasznál elhaló munkamenetek általában arra vezethetők vissza, hogy ezt az összeadást találgatással végezték.

Rétegenként külön ellenőrizd, kívülről befelé

Futtasd az ellenőrzéseket sorban, és állj meg az elsőnél, amelyik elbukik. Minden sor más kérdésre válaszol, így a hiba a munkalap egyik oszlopára mutat, nem pedig arra, hogy az alagút elromlott.

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-eszközön a megfelelő művelet szerepfüggő, és a pontos szintaxis platformtól és kiadástól függ: show crypto session az IPsec partnerekhez, interfész-számlálók a GRE- vagy alagút-interfészhez, és a VPDN- vagy PPP-ellenőrzés a betárcsázós szerephez. Egy PPP-t lezáró parancskészlet semmit sem bizonyít a GRE-támogatásról, egy működő GRE-interfész pedig semmit a PPP-szolgáltatásról, ezért a ténylegesen beállított szerepet ellenőrizd, ne a diagramon szereplőt.

Jegyezd fel az egyes kimeneteket a hozzá tartozó munkalapsor mellé. A hiba fennállása alatt készült jegyzetek többet érnek egy később emlékezetből újrarajzolt topológiánál.

Rendezd a bontás sorrendjét, majd ellenőrizz újra

A bontás fordított sorrendben fut, okkal: vedd ki a védett forgalmat az IPsec-szabályzatból, mielőtt eltávolítod azt a becsomagolást, amelyre a szabályzatot írták, különben a szabályzat továbbra is egy nem létező interfészre mutat, és a következő konfigurációbetöltés valahol, látszólag független helyen bukik el. Linuxon ez az állapot- és szabályzatbejegyzések törlését jelenti az alagút-interfész előtt; routeren a crypto map vagy profile bejegyzés eltávolítását az alagút előtt.

Az újjáépítés után ismételd meg a négy elfogadási megfigyelést egyenként: külső elérhetőség, létrejött IPsec-társítás, létrejött PPP-munkamenet ott, ahol a terv tartalmaz ilyet, és belső továbbítás egy valódi célcímre. Egy zöld lámpa nem bizonyíték a másik háromra, és ez a rés a leghosszabb ideig túlélő hiba a termelésben — egy alagút, amely fent van, titkosított, és semmit sem továbbít, mert a belső útvonal soha nem került hozzáadásra.

Tartsd a kitöltött munkalapot az eszköz konfigurációja mellett. Bármely oszlop, amelyet nem tudsz kitölteni, olyan réteg, amelynek nincs kiosztott feladata, és a kiosztott feladat nélküli réteg általában olyan réteg, amelynek nem lenne szabad a veremben lennie.