NAT-greining svarar einni spurningu: hafa vistföngin eða gáttirnar breyst á leiðinni? Hún svarar ekki hvort eldveggur leyfir IP-samskiptareglu 50. Síðuhlið án nokkurrar túlkunar geta samt staðið bak við stefnu sem hendir native ESP, og þá kröfu verður að stilla frekar en uppgötva. Aðferðin er ESP-in-UDP, og það er ákvörðun, ekki varaleið sem birtist af sjálfu sér.

Greining er reikningur á vistföngum, ekki eldveggsprófun

IKEv2 ber NAT-greiningargögn sem innihalda tætigildi upprunans og áfangavistfanga og gátta. Hvor hlið ber saman það sem hún fékk við það sem hún sér staðbundið, og ósamræmi segir henni að eitthvað hafi túlkað pakkann. Ekkert í þeim skiptum prófar hvort beinir í miðjunni sendi samskiptareglu 50 áfram.

Aðferðin í reynd er þess virði að segja hana berum orðum. Göng sem virkuðu með native ESP munu ekki uppgötva nýjan takmarkandi eldvegg af sjálfu sér, og næsta tilraun þeirra mistekst á gagnastiginu meðan IKE heldur áfram að takast. Þú munt sjá uppsettar IKE-öryggistengingar og engan varinn umferð, sem lítur út eins og villu í beiningu þar til þú grípur á vírnum.

Innheimtun er því eiginleiki tengingarinnar sem þú stillir, ekki niðurstaða sem aðilar semja um út frá hegðun netsins.

Hvernig encap breytir skiptunum

Í nútíma strongSwan-uppsetningu sem stýrt er í gegnum swanctl.conf, hefur stillingin encap = yes á tengingunni áhrif á NAT-greiningarskiptin svo báðir aðilar noti UDP-innheimtun fyrir ESP. Vernduðu pakkarnir ferðast þá inni í UDP, venjulega á gátt 4500, og báðir endar verða að vera sammála um það fyrirkomulag.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Sá bútur tilheyrir raunverulegri tengingarskilgreiningu og er ekki heilt síðusnið. Haltu jafningjavistföngunum, auðkenningunni og child-umferðarvalunum sem þú keyrir þegar; eini viðbættur lykillinn breytir því hvernig vernduðu gögnin eru vafin inn, ekki því sem þau verja.

Leiðarvísir strongSwan um NAT-traversal lýsir þessari hegðun, þar á meðal samspilinu við gáttarflot þegar MOBIKE er notað.

Notaðu stillinguna sem tilheyrir bakendanum þínum

strongSwan hefur tvo stillingabakenda, og lykillinn er mismunandi á milli þeirra. swanctl.conf tenging tekur encap, en eldri ipsec.conf tenging tekur forceencaps. Að setja leitarorð eins bakenda í hinn framleiðir stillingu sem hleðst án kvartana og breytir engu, sem er verra en villa.

Athugaðu hvaða dæmon er í raun í gangi áður en þú breytir einhverju. Í mörgum dreifingum eru báðar skrárnar til vegna þess að önnur er leif frá fyrri flutningi, og virka er sú sem þjónustueiningin ræsir. Lestu þá einingu í stað þess að giska út frá tímasetningum skráa. Fimm sekúndna athugun hér kemur í veg fyrir klukkustundir af prófun stillingar sem ekkert hlóð.

Beittu breytingunni í gegnum eiganda tengingarinnar og endurreistu samtengingu í stýrðum glugga. Uppsett child heldur núverandi innheimtun sinni þar til skipt er um það, svo skrárbreyting ein og sér sannar ekki að nýja fyrirkomulagið sé í notkun.

Sannprófaðu vöfnu gögnin, ekki bara gáttina

Gríptu á hliðinu meðan varin umferð streymir, og berðu það svo saman við eigin sýn strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP birtist sem IP-samskiptaregla 50 og líkist UDP ekkert. Vafið ESP birtist sem UDP-gagnapakkar á 4500 sem hafa ekki IKE sem hyrnu. IKE-umferð á sömu gátt er ekki sönnun innheimtunar, því MOBIKE getur fært IKE þangað meðan gagnaleiðin er áfram native, svo lestu hyrnuna, ekki gáttarnúmerið.

Hafðu líka MTU leiðarinnar í huga. Umbúðirnar bæta við yfirálagi, og leið sem bar native ESP gæti þurft aðlögun þegar pakkarnir stækka. Nauðsynleg ICMP-meðferð ætti þegar að vera hluti hönnunarinnar; innheimtun fjarlægir ekki þá háð.

Samþykktu breytinguna þegar fersk forritsumferð inni í göngunum er sýnileg í gripnum sem vafið ESP á báðum endum, og þegar innri þjónustan og afturleið hennar virka enn. Hvað sem er minna er stilling sem lítur rétt út í skrá.

Tengdir greinar