Fiif adresrollen yn in IPsec-profyl, en hokker is ferkeard
Einpunt, identiteit, beskerme subnet, gateway-boarne en folgjende hop beantwurdzje elk in oare fraach. Keppelje earst it symptoom oan it fjild.
Fiif ferskate taken krije in adres yn in typyske ferbiningdefinysje, en se hoege net mei elkoar oerien te kommen. Behearders rinne fêst omdat in ferstannige ynsstinkt, alle fjilden nei deselde host wize litte, foar teminsten trije fan har ferkeard is. De útwei is earst it symptoom te neamen en dan te sjen nei it iene of de twa fjilden dy't it feroarsaakje kinne.
De fiif taken, yn 'e folchoarder wêryn't se ta docht
It ferfier-einpunt is dêr't de IKE-útwikseling besoarge wurdt. De autentisearre identiteit is de namme dy't elke kant bewissiget, en dy wurdt toetst oan belied, net oan in rûtingstabel. De beskerme subnetten binne de selektors dy't beslute hokker ynterne ferkear by de tunnel heart. Dan is der de boarne dy't brûkt wurdt as de gateway sels in petear begjint, en as lêste de folgjende hop fan 'e ûnderlaach om de peer te berikken.
Dielnimmerlabels lykas left en right binne konvinsjes foar twa kanten fan in ferbining, net synonimen foar lokaal en fier. Lês de hânlieding fan 'e ymplemintaasje dy't eins ynstallearre is foardat jo oannimme dat in kaai betsjut wat in oar produkt der ûnder ferstie.
| Job | Typical key | What fails when it is wrong |
|---|---|---|
| Transport endpoint | left, right | No IKE exchange at all |
| Authenticated identity | leftid, rightid | Exchange starts, peer rejects it |
| Protected subnets | leftsubnet, rightsubnet | Tunnel up, traffic not selected |
| Gateway source | leftsourceip, rightsourceip | Only gateway-originated flows fail |
| Underlay next hop | leftnexthop, rightnexthop | Peer unreachable from this host only |
Beslissing ien: neat komt ta stân
As der hielendal gjin útwikseling yn 'e lochboeken ferskynt, is it einpunt de earste fertochte: in ferkeard adres, in filtere paad of in ynterface dêr't de daemon net op harket. Gean pas nei de identiteitsfjilden as in hânskodding sichtber is, want identiteit wurdt binnen de útwikseling beoardiele, net dêrfoar. In filtere paad en in ferkeard adres sjogge fan 'e klant ôf identyk út, dus kontrolearje de harkende kant foardat jo eat bewurkje. Befêstigje dat de daemon oan it ynterface bûn is dat jo ferwachtsje, want in tsjinst dy't op ien adres harket sjocht der krekt itselde út as in blokkearre paad.
In iepenbier adres dat troch oersetting sjoen wurdt is net itselde ding as de identiteit dy't in peer bewissiget. In adres feroarje om it oerien te litten kommen mei wat in pakketfangst oan 'e fiere kant sjen lit, is in gewoane en ferkearde korreksje.
Beslissing twa: de tunnel stiet en it ferkear stjert
Selektors beslute wat de tunnel yn giet, en in mismatch hjir jout in ferbining dy't mei súkses ûnderhannelet wylst de tapassing noch hieltyd mislearret. De fiere kant moat jo beskerme berik as syn fiere berik neame, en dêr krekt glûpe omkearde wearden nei binnen.
Lês beide konfiguraasjes njonken elkoar foardat jo bewurkje. It lokale berik op 'e iene host is it fiere berik op 'e oare, en ien omruile pear ferklearret in tunnel dy't neat draacht. Fernauje it pear foardat jo de kaaien oanreitsje: ien subnet yn 'e tunnel en ien derbûten fertelt jo oft de selektor of de rûting skuld hat.
Beslissing trije: allinnich it eigen ferkear fan 'e gateway mislearret
Ferkear dat foar klanten trochstjoerd wurdt kin perfekt wurkje wylst in fersyk dat de gateway sels begjint mislearret, omdat dy stream gjin klantboarne hat om te erven. De ynstelling foar foarkarboarne bestiet foar dit gefal, en it is gjin boarne-oersetting: it kiest in boarneadres yn stee fan ien te werbeskriuwen.
In tapassing dy't eksplisyt in oar adres bûn hat kin de foarkar oerskriuwe, dus befêstigje de werklike boarne fan it pakket foardat jo konkludearje dat de ynstelling negearre wurdt. Fange op it eigen ynterface fan 'e gateway yn stee fan op 'e bedoeling fan 'e konfiguraasje te fertrouwen.
De folgjende hop is in lokale opdracht
De folgjende hop fan 'e ûnderlaach fertelt dizze host hoe't er de peer berikt, en de fiere kant hat deselde wearde net nedich. It behannelje as in dielde ynstelling, of in standertgateway hurd kodearje, brekt op it stuit dat de rûte feroaret of in twadde paad ferskynt.
Guon ymplemintaasjes biede hjir spesjale wearden. Wat de hânlieding foar de ynstallearre ferzje neamt is it iennichst feilige antwurd, en de lokale rûtingstabel is it bewiis dat it wurke hat. As in peer by namme berikber is mar net by adres, dan is dy mismatch de fynst, net in detail om omhinne te wurkjen.
Lês it profyl fan beide kanten
De rollen op papier omkeare is de fluchste resinsje dy't der is: ruilje de beskerme berikken om, hâld de eigen folgjende hop fan elke kant en de eigen identiteit fan elke kant. Alles dat de omrúling net oerlibbet is wierskynlik oan 'e ferkearde taak tawiisd.
Testje dan ien stream per rol: berikberens tusken peers, in ynterne klantstream en in fersyk dat fan 'e gateway út giet. Trije tests fertelle jo hokker taak ferkeard tawiisd is sûnder de konfiguraasje opnij te iepenjen. Foegje it resultaat ta oan 'e kaart njonken it fjild dat jo feroare hawwe, want de folgjende yngenieur treft itselde profyl.