Neniu tun0? Kongruigu malĉifritan IPsec en nftables per meta ipsec

Vi atendas tunelan interfacon, serĉas ĝin, kaj estas nenio por kongruigi en la fajroŝirmilo. Tio normalas por regulbazita pordego: la ĉifrita interŝanĝo alvenas sur la fizika interfaco, kaj la malĉifrita interna pakaĵo, kiu poste plusendiĝas, ankaŭ observeblas kiel alvenanta sur tiu sama interfaco. Ne estas tun0, ĉar nenio kreis ĝin.

La interna peto ankoraŭ estas aparta pakaĵo kun propra fonto, celo kaj servo, kaj la kerno scias, el kiu sekureca asociĝo ĝi eliris. Ĝuste tiu scio estas kion fajroŝirmila regulo povas kongruigi.

Du pakaĵoj, unu interfaco

Imagu la envenan direkton. ESP- aŭ UDP-enkapsulita pakaĵo alvenas, la kerno trovas la kongruan regulon, malĉifras ĝin kaj transdonas la klaran pakaĵon al la plusenda vojo. Regulo, kiu rigardas nur la nomon de la interfaco, ne povas distingi tiun pakaĵon de iu ajn alia trafiko alvenanta sur la sama drato.

Tio, kio distingas ĝin, estas la kunteksto de la envena sekureca vojo alkroĉita al la pakaĵo. nftables elmetas ĝin kiel meta ipsec exists, kio veras kiam la pakaĵo alvenis tra IPsec-sekureca vojo. Kombinu ĝin kun la klienta provizo, la celo kaj la servo, kaj la regulo fariĝas sufiĉe specifa por esti sekura.

Forlasi la kuntekston estas la kutima eraro, kaj ĝi estas sekureca eraro, ne kosmetika. Regulo, kiu akceptas ion ajn devenantan el la klienta provizo, same volonte akceptas falsitan pakaĵon el la loka reto, ĉar la fonta adreso per si mem ne estas pruvo de io ajn. La kunteksto de la sekureca vojo estas la plej malmultekosta maniero igi la fonton signifoplena. Skribu la regulon kun ĝi de la komenco anstataŭ aldoni ĝin post revizio.

Skribu la plusendan regulon

Supozu aŭtentikigitan IPv4-retan alirservon kun klientoj en 10.90.0.0/24 kaj unu aprobitan celon ĉe 203.0.113.40. Regulfragmento por tiu fluo aspektas tiel.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

La adresoj kaj la interfaco estas ekzemploj anstataŭigendaj. Metu la reviziitan ekvivalenton en la plusendan regulon antaŭ la regulo, kiu alie malakceptus la fluon, kaj ne malplenigu ekzistantan regulparon por instali ĝin; pordego ne estas eksperimento en pura ĉambro.

La termino oifname indas resti. Ĝi dokumentas la eligan decidon kaj malhelpas al la regulo kongrui en direkto, kiun vi ne intencis, kio gravas ĉe pordego kun pluraj vojoj al la interreto. Sur unu-ligila testa maŝino la termino ŝajnas superflua, kaj ĝuste tial ĝi foriĝas antaŭ ol la maŝino ricevas duan ligilon.

Permesoj por la ekstera interŝanĝo estas apartaj. La enira vojo de la pordego bezonas la havenojn IKE kaj ESP aŭ UDP-enkapsuligajn, kiujn ĝi efektive uzas, kaj tiuj permesoj rajtigas nenion pri la malĉifrita pakaĵo interne. Miksi la du estas la maniero, per kiu funkcianta tunelo finiĝas kun fajroŝirmilo, kiu plusendas ĉion.

Envena kunteksto ne estas elvena kunteksto

La sama familio de esprimoj kovras la alian direkton per rt ipsec, kiu priskribas la elvenan sekurecan asociĝon, kiun pakaĵo uzos. Ĝi respondas al alia demando: ne de kie ĉi tiu pakaĵo venis, sed ĉu ĝi estos protektita en sia sekva etapo.

Tiu distingo gravas ĉe pordego, kiu samtempe finas unu tunelon kaj plusendas en alian. Pakaĵo povas alveni malĉifrita kaj tamen devi eliri ĉifrita, kaj akcepto skribita nur por la envena kunteksto diras nenion pri la elvena postulo. Se la regulo postulas tiun protekton, la regulparo esprimu ĝin anstataŭ supozi, ke la enkursigado traktos ĝin.

Tenu la du demandojn en apartaj reguloj, por ke leganto vidu, kiu estas trudata. Unu lerta regulo, kiu kontrolas ambaŭ, estas pli malfacile revizebla kaj multe pli malfacile sencimigebla, kiam unu duono ĉesas kongrui. Du reguloj kun nombriloj ankaŭ diras al vi, kiu postulo malsukcesas, kion unu kombinita regulo neniam faros.

NAT ne estas fajroŝirmila decido

Trafiko al la interreto el privata klienta provizo kutime bezonas fontan tradukon, por ke la respondo trovu sian vojon reen. Sed trafiko elektita por alia elvena IPsec-regulo devas konservi sian postulatan escepton, kaj maski ĉiun privatan fonton sen pripensi la sekvan protektan decidon rompas tion.

Akcepto ene de NAT-ĉeno ankaŭ ne estas ĝenerala permeso. NAT kaj filtrado havas malsamajn taskojn, kaj NAT-ĉeno ne ekzamenas ĉiun postan pakaĵon de establita fluo, kaj ĝuste tial fidi ĝin por sekureco produktas regulojn, kiuj ŝajnas funkcii en testoj kaj malsukcesas sub ŝarĝo.

La malo ankaŭ veras kaj surprizas homojn: akcepto ie en unu baza filtra ĉeno havas neniun pezon kontraŭ posta malakcepto en alia aplikebla ĉeno. Ordo kaj amplekso de la ĉeno decidas la rezulton, ne la ĉeesto de akcepto en la dosiero.

Kontrolu la ĝustan internan servon

Testu la konkretan celon kaj havenon, kiujn vi rajtigis, el reala kliento, kaj konfirmu, ke la respondo revenas. Poste testu ion, kion vi ne rajtigis, kaj kontrolu, ke ĝi ne trapasas, ĉar tro larĝa regulo trapasas la unuan teston same bone kiel ĝusta. Peto, kiu neniam forlasas la klienton, ankaŭ ne estas fajroŝirmila rezulto, do legu la nombrilojn por vidi, ĉu la pakaĵo entute estis taksita. Du testoj kaj unu nombrila legado diros al vi pli ol tuta posttagmezo da legado de la regulparo.

La nftables-referenco dokumentas meta ipsec, rt ipsec kaj la direkto-specifajn esprimojn, kaj ĝuste tie oni kontrolas la sintakson kontraŭ la instalita versio. Kaj tenu la amplekson eksplicita: ĉi tio estas IPv4-ekzemplo, ĝi diras nenion pri IPv6, kaj ĝi ne faras arbitran publikan havenan plusendadon parto de la VPN-servo.