Gjin tun0? Koppel ûntsifere IPsec yn nftables oan meta ipsec

Jo ferwachtsje in tunnel-ynterface, jo sykje dernei, en der is neat yn 'e fjoermuorre om oan te koppeljen. Dat is normaal foar in beliedsbasearre gateway: de fersifere útwikseling komt oan op 'e fysike ynterface, en it ûntsifere ynderlike pakket dat dêrnei trochstjoerd wurdt, wurdt ek waarnommen as oankommend op deselde ynterface. Der is gjin tun0, om't neat der ien makke hat.

It ynderlike fersyk is noch altyd in apart pakket mei syn eigen boarne, bestimmingsplak en tsjinst, en de kearn wit út hokker feilichheidsassosjaasje it kaam. Krekt dy kennis kin in fjoermuorrel oankoppelje.

Twa pakketten, ien ynterface

Stel jo de ynkommende rjochting foar. In ESP- of UDP-ynkapsele pakket komt oan, de kearn fynt it byhearrende belied, ûntsiferet it en jout it heldere pakket oan it trochstjoerpaad. In regel dy't allinnich nei de namme fan 'e ynterface sjocht, kin dat pakket net fan oare ferkear op deselde tried ûnderskiede.

Wat it ûnderskiedt, is de kontekst fan it ynkommende feilichheidspaad dy't oan it pakket ferbûn is. nftables toant dat as meta ipsec exists, wat wier is as it pakket fia in IPsec-feilichheidspaad oankaam. Kombinearje it mei de kliïntepool, it bestimmingsplak en de tsjinst, en de regel wurdt spesifyk genôch om feilich te wêzen.

De kontekst weilitte is de gewoane flater, en it is in feilichheidsflater en net in kosmetyske. In regel dy't alles akseptearret dat fan 'e kliïntepool komt, akseptearret like graach in ferfalske pakket fan it lokale netwurk, om't it boarnealder op himsels gjin bewiis fan wat is. De kontekst fan it feilichheidspaad is de goedkeapste manier om de boarne betsjuttingsfol te meitsjen. Skriuw de regel der fan it begjin ôf mei, ynstee fan him nei in audyt ta te foegjen.

Skriuw de trochstjoerregel

Stel in autentisearre IPv4-ôfstânsferbiningstsjinst foar mei kliïnten yn 10.90.0.0/24 en ien goedkarde bestimmingsplak op 203.0.113.40. In regelfragmint foar dy stream sjocht der sa út.

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

De adressen en de ynterface binne foarbylden om te ferfangen. Pleats it neisjoene ekwivalint yn it trochstjoerbelied foar de regel dy't de stream oars ôfwize soe, en meitsje gjin besteande regelset leech om it te ynstallearjen; in gateway is gjin skjinne-keamer-eksperimint.

De term oifname is it wurdich om te hâlden. Hy dokumintearret it útgongsbeslút en foarkomt dat de regel yn in rjochting oankoppelet dy't jo net bedoelden, wat fan belang is op in gateway mei ferskate paden nei it ynternet. Op in testkast mei ien uplink liket de term oerstallich, en krekt dêrom wurdt er fuorthelle foardat de kast in twadde uplink krijt.

Tastimmingen foar de bûtenste útwikseling binne apart. It yngongspaad fan 'e gateway hat de IKE- en ESP- of UDP-ynkapselingspoarten nedich dy't er echt brûkt, en dy tastimmingen tastean neat oangeande it ûntsifere pakket binnenyn. It ien mei it oare mjukskje is de manier wêrop in wurkjende tunnel belânet by in fjoermuorre dy't alles trochstjoert.

Ynkommende kontekst is gjin útgeande kontekst

Deselde famylje útdrukkingen beslacht de oare rjochting mei rt ipsec, dat de útgeande feilichheidsassosjaasje beskriuwt dy't in pakket brûke sil. It beantwurdet in oare fraach: net wêr't dit pakket wei kaam, mar oft it op syn folgjende skonke beskerme wurdt.

Dat ûnderskie is fan belang op in gateway dy't tagelyk ien tunnel beëiniget en nei in oare trochstjoert. In pakket kin ûntsifere oankomme en dochs fersifere fuort moatte, en in akseptaasje dy't allinnich foar de ynkommende kontekst skreaun is, seit neat oer de útgeande eask. As it belied dy beskerming easket, moat it regelset dat útdrukke ynstee fan oan te nimmen dat de routing it wol dwaan sil.

Hâld de twa fragen yn aparte regels, sadat in lêzer sjen kin hokker fan beide hanthavene wurdt. Ien tûke regel dy't beide kontrolearret, is dreger nei te sjen en folle dreger te debuggen as ien helte derfan ophâldt mei oankoppeljen. Twa regels mei tellers fertelle jo ek hokker eask mislearret, wat ien kombinearre regel nea dwaan sil.

NAT is gjin fjoermuorrebelslút

Ferkear nei it ynternet út in partikuliere kliïntepool hat meastentiids boarneoersetting nedich sadat it antwurd syn wei werom fine kin. Mar ferkear dat foar in oar útgeand IPsec-belied keazen is, moat syn fereaske útsûndering hâlde, en elk partikulier adres maskearje sûnder oan it folgjende beskermingsbeslút te tinken brekt dat.

In akseptaasje binnen in NAT-ketting is ek gjin algemiene tastimming. NAT en filterjen hawwe ferskillende taken, en in NAT-ketting ûndersiket net elk letter pakket fan in fêstige stream, en krekt dêrom jout fertrouwen derop foar feilichheid regels dy't yn 'e test wurkje lykje en ûnder belesting mislearje.

It omkearde is ek wier en ferrast minsken: in akseptaasje earne yn ien filterbasiskeatling hat gjin gewicht tsjin in lettere ôfwizing yn in oare tapasbere keatling. Oarder en omfang fan 'e keatling beslisse de útkomst, net de oanwêzigens fan in akseptaasje yn it bestân.

Kontrolearje de krekte ynderlike tsjinst

Test it spesifike bestimmingsplak en de poarte dy't jo tastien hawwe, fan in echte kliïnt, en befêstigje dat it antwurd weromkomt. Test dêrnei eat dat jo net tastien hawwe en kontrolearje dat it net trochkomt, om't in te brede regel de earste test like goed trochstiet as in krekte. In fersyk dat de kliïnt nea ferlit is ek gjin fjoermuorrerêsultaet, dus lês de tellers om te sjen oft it pakket oait beoardiele is. Twa tests en ien tellerlêzing fertelle jo mear as in hiele middei regelset lêze.

De nftables-referinsje dokumintearret meta ipsec, rt ipsec en de rjochtingspesifike útdrukkingen, en dat is it plak om de syntaksis tsjin jo ynstalleare ferzje te kontrolearjen. En hâld it omfang eksplisyt: dit is in IPv4-foarbyld, it seit neat oer IPv6, en it makket willekeurige iepenbiere poartetrochstjoering gjin diel fan 'e VPN-tsjinst.