Kial via iptables-regulo neniam vidas pontigitan VPN-trafikon

Du virtualaj maŝinoj sur la sama gastiganto atingas la LAN per ponto, kaj regulo metita en la ip forward-ĉenon montras nombrilon, kiu neniam moviĝas. La kadroj estas realaj, la trafiko pasas, kaj la regulo simple ne estas sur ĝia vojo. Kompari la du manierojn, laŭ kiuj Linux elmetas pontigitan trafikon, klarigas tiun silenton, kaj ĝi ankaŭ klarigas, kial ŝargi unu malnovan modulon estas pli malbona respondo, ol ĝi ŝajnas.

Du vojoj tra unu gastiganto

Pako povas forlasi ĉi tiun gastiganton laŭ du tre malsamaj manieroj, kaj la diferenco decidas, kiuj hokoj vidos ĝin. Se la celo estas malantaŭ fizika pordo kaj la kadro estas komutata inter du pontaj pordoj, la gastiganto plusendas Ethernet-kadron; la enkursiga kodo ne estas konsultata, kaj nenia enkursigita salto okazas. Se la celo estas la gastiganto mem, aŭ reto atingata per tunela interfaco, la pako estas enkursigata kaj la hokoj de la IP-tavolo ja aplikiĝas. Konservu tiun disforkiĝon en la menso, ĉar ĉiu posta demando pri ĉenoj kaj familioj sekvas el tio, kiun el la du vojoj kadro prenas.

Tiu distingo estas la tuta historio malantaŭ regulo, kiu kalkulas nenion. Pontigita kadro de veth9a1 al enp3s0 transiras la ponton, ne la IP-stakon, do ip forward-ĉeno vidas nenion por kongrui. Interfacaj nomoj en pli malnova ekzemplo ne decidas, kiun vojon vi havas, kaj tial la unua paŝo estas rigardi la topologion anstataŭ la regularon.

Tunelo aldonas trian kazon indan je nomo. TUN-aparato liveras IP-pakojn al la gastiganto, do tiuj estas enkursigataj kaj ja trapasas IP-ĉenojn, dum TAP-aparato ligita al ponto liveras kadrojn kaj kondutas kiel la pontigita kazo. La aparata tipo, ne la produkta nomo, decidas.

Komparu la du familiojn, kiuj povas vidi pontigitan kadron

Linux subtenas indiĝenan pontan filtradon per la bridge-familio de nftables, kaj ĝi bezonas neniun malnovan modulon por inspekti kaj forĵeti kadrojn dum flugo. La propra ponta dokumentaro de la kerno donas tiun rekomendon rekte, kion indas scii antaŭ ol serĉrezulto diros al vi ŝargi modulon.

Uzi la komandon nft anstataŭ iptables mem ne metas regulon en la ĝustan familion. Ĉeno deklarita en la bridge-familio vidas kadrojn; ĉeno deklarita en ip, ip6 aŭ inet ne vidas, sendepende de tio, kiu binaraĵo kreis ĝin. La familio estas eco de la ĉeno, ne de la ilo, kiu tajpis ĝin.

La malnova vojo funkcias alie, kaj tio estas la kialo kompari anstataŭ elekti flankon pro kutimo. Ŝargi br_netfilter kaj ebligi la agordojn bridge-nf-call denove elmetas pontigitan IPv4- kaj IPv6-trafikon tra la hokoj de la IP-tavolo, tiel ke ordinara iptables-regulo finfine povas kongrui ĝin. La kadroj ne ŝanĝiĝas; la aro de hokoj, kiujn ili transiras, ŝanĝiĝas, kio signifas, ke ĉiu ekzistanta gastiganta regulo nun havas novan publikon.

Legu la efektivan vojon antaŭ ol aldoni regulon

Tri komandoj establas, kie vi estas: al kio la ponto estas ligita, ĉu la malnova modulo estas aktiva, kaj kiuj ĉenoj jam ekzistas en la bridge-familio. Rulu ilin antaŭ ol skribi ion ajn, ĉar la respondo decidas, kiun el la du dizajnoj vi etendas. Pretersalti ĉi tiun paŝon estas la maniero, kiel ĝusta regulo finiĝas en ĉeno, kiun nenio transiras.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

La eligo klare apartigas la kazojn. Pordoj listigitaj sub la ponto diras al vi, kiuj interfacoj estas komutataj; malplena lsmod-rezulto signifas neniun videblecon je la IP-tavolo de pontigitaj kadroj; ekzistanta forward-ĉeno de la bridge-familio signifas, ke politikposedanto jam ekzistas kaj via regulo apartenas tien, ne en novan propran ĉenon.

Poste aldonu unu regulon facile relegeblan, kun nombrilo kaj sen ŝanĝo de la verdikto, kaj sendu unu reprezentan fluon tra la ponto. Nombrilo, kiu moviĝas, pruvas, ke la kadro atingis la regulon. Tio estas ĉio, kion ĝi pruvas, do sekvu ĝin ankaŭ per la malpermesita vojo, ĉar politiko, kiu akceptas ĉion, ankaŭ produktas moviĝantan nombrilon.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Kie la malnova modulo ŝanĝas konduton

Ebligi la malnovan vojon sur funkcianta ponto ne estas neŭtrala ago aldoni videblecon. Reguloj antaŭe neatingeblaj por pontigita trafiko fariĝas atingeblaj, inkluzive de gastigantaj reguloj skribitaj por alia interfaco, kaj defaŭlta drop-politiko en la ip forward-ĉeno povas subite aplikiĝi al kadroj, kiuj antaŭe pasis netuŝitaj. Sur gastiganto administrata tra tiu ponto, la rezulto estas ŝloso sen konzolo. Tio ne estas hipoteza fiaska reĝimo; ĝi estas la ordinara sekvo de larĝigo de hokaro sur maŝino, kiun vi atingas tra la vojo, kiun vi ĵus larĝigis.

La pli sekura sinsekvo estas decidi, kiu familio posedas la politikon, skribi la regulojn tie, kaj konservi sendependan rekuperan vojon antaŭ ol ŝanĝi ajnan sysctl. Se du familioj ambaŭ tenas regulojn, dokumentu, kiu estas aŭtoritata; du interkovrantaj politikoj estas la maniero, kiel pako akceptiĝas en unu loko kaj forĵetiĝas en alia sen unu sola dosiero legebla.

Izolado mem ankoraŭ bezonas plenan dizajnon. Permesi unu fonton al unu celo pruvas nur, ke unu fluo funkcias, dum la postulo kutime estas, ke VM ne povu atingi siajn najbarojn aŭ la gastiganton. Nombriloj sur la malpermesaj reguloj pli gravas ol la nombrilo sur la akcepta regulo, ĉar la akcepta nombrilo estas tiu, kiun vi jam atendis moviĝi.

Fine, tenu la kazon de gastiganta enigo aparte. Trafiko adresita al la propra IP de la ponto alvenas ĉe input, ne ĉe forward, kaj regulo en forward neniam vidos ĝin, kiun ajn familion vi elektos. Tri kazoj, du familioj, unu leciono: la vojo decidas la hokon, kaj la hoko decidas, ĉu via regulo entute ekzistas.