ولې ستاسو iptables قاعده هېڅکله د پل له لارې VPN ټرافیک نه ویني
د پل له لارې تېرېدونکي چوکاټونه کولای شي هغه IP زنځیر چې تاسو څارئ مخامخ کړي. د بلې قاعدې له زیاتولو مخکې اصلي bridge کورنۍ له زړې br_netfilter سره پرتله کړئ.
په یوه هوسټ کې دوه مجازي ماشینونه د پل له لارې LAN ته رسېږي، او په ip forward زنځیر کې اېښودل شوې قاعده هغه شمېرښت ښیي چې هېڅکله نه خوځېږي۔ چوکاټونه ریښتیني دي، ټرافیک تېرېږي، او قاعده یوازې د هغه په لاره کې نه ده۔ د دوه لارو پرتله چې Linux پر پل تېرېدونکی ټرافیک ښیي، دا غلې تشرېح کوي، او دا هم تشرېح کوي چې ولې یو زړ ماډل لوستل د هغه له ښکارېدنې څخه بدتر ځواب دی۔
د یوه هوسټ له لارې دوه لارې
بسته کولای شي دا هوسټ په دوه ډېرو بېلو لارو پرېږدي، او توپیر ټاکي چې کوم هوکونه به یې وویني۔ که منزل د یوه فزیکي پورټ هاخوا وي او چوکاټ د پل د دوو پورټونو ترمنځ سویچ شي، هوسټ یو Ethernet چوکاټ وړاندې لېږي؛ د لارښوونې کوډ نه پوښتل کېږي، او هېڅ لارښوول شوی ټوپ نه پېښېږي۔ که منزل پخپله هوسټ وي، یا هغه شبکه چې د تونل انټرفېس له لارې ورته رسېږي، بسته لارښوول کېږي او د IP طبقې هوکونه واقعاً پلي کېږي۔ دا دوه ښاخه په یاد وساتئ، ځکه چې د زنځیرونو او کورنیو په اړه هر وروستی پوښتنه له دې څخه راځي چې چوکاټ د دوو لارو کومه غوره کوي۔
دا توپیر د هغې قاعدې شاته ټوله کیسه ده چې هېڅ نه شمېري۔ د veth9a1 نه enp3s0 ته پل شوی چوکاټ IP سټیک نه، پل تېروي، نو ip forward زنځیر د ورته کولو لپاره هېڅ نه ویني۔ په زړه بېلګه کې د انټرفېسونو نومونه نه ټاکي چې تاسو کومه لاره لرئ، او له همدې کبله لومړی ګام د قاعدو ټولګې ته نه، بلکې ټوپولوژي ته کتل دي۔
تونل درېیمه پېښه زیاتوي چې د نومولو وړ ده۔ د TUN وسیله IP بستې هوسټ ته سپاري، نو هغه لارښوول کېږي او واقعاً د IP زنځیرونو له لارې تېرېږي، خو د پل سره تړلې TAP وسیله چوکاټونه سپاري او لکه د پل پېښه چلند کوي۔ د وسیلې ډول ټاکي، د محصول نوم نه۔
هغه دوه کورنۍ پرتله کړئ چې پل شوی چوکاټ ویني
Linux له nftables د bridge کورنۍ له لارې اصلي پل فلټر کول ملاتړ کوي، او د الوتنې پر مهال د چوکاټونو کتلو او غورځولو لپاره هېڅ زړ ماډل ته اړتیا نه لري۔ د کرنل خپل د پل اسناد دا سپارښتنه مستقیم ورکوي، چې د لټون پایله به تاسو ته د ماډل لوستلو ووایي، مخکې یې پوهېدل ارزښت لري۔
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
د iptables پرځای د nft کمانډ کارول پخپله قاعده په سمه کورنۍ کې نه اېږدي۔ په bridge کورنۍ کې اعلان شوی زنځیر چوکاټونه ویني؛ په ip، ip6 یا inet کې اعلان شوی زنځیر هغه نه ویني، که هر بائنري یې جوړ کړی وي۔ کورنۍ د زنځیر ځانګړنه ده، د هغه وسایل نه چې ټایپ کړی یې دی۔
زړه لاره بل ډول کار کوي، او له همدې کبله د عادت له مخې د یوې خوا غوره کولو پرځای پرتله کول ښه دي۔ د br_netfilter لوستل او د bridge-nf-call امستنو فعالول بیا هم د پل له لارې IPv4 او IPv6 ټرافیک د IP طبقې هوکونو له لارې څرګندوي، نو یوه عادي iptables قاعده کولای شي په پای کې ورسره سمه شي۔ چوکاټونه نه بدلېږي؛ هغه هوکونه بدلېږي چې تېرېږي، دا مانا چې هره موجوده د هوسټ قاعده اوس نوی اورېدونکی لري۔
د قاعدې له زیاتولو مخکې مؤثره لاره ولولئ
درې کمانډونه ټاکي چې تاسو چېرې یاست: پل له څه سره تړلی دی، زړ ماډل فعال دی که نه، او په bridge کورنۍ کې کوم زنځیرونه مخکې موجود دي۔ هغه وړاندې چلاوئ چې څه ولیکئ، ځکه ځواب ټاکي چې د دوو ډیزاینونو کوم یو غځوئ۔ دا ګام پرېښودل هغه لاره ده چې سمه قاعده په هغه زنځیر کې ورګډېږي چې هېڅ نه تېرېږي۔
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"پایله پېښې پاکې بېلوي۔ د پل لاندې لیست شوي پورټونه وایي کوم انټرفېسونه سویچ کېږي؛ تشه lsmod پایله مانا دا ده چې د پل شوو چوکاټونو د IP طبقې هېڅ لید نشته؛ په bridge کورنۍ کې موجود forward زنځیر مانا دا ده چې د پالیسي مالک مخکې موجود دی او ستاسو قاعده هلته ځي، نه خپل نوي زنځیر ته۔
بیا هغه قاعده زیاته کړئ چې بېرته لوستل یې اسانه وي، له شمېرښت سره او پرېکړه نه بدلېدونکې، او یو استازې بهیر د پل له لارې ولېږئ۔ خوځېدونکی شمېرښت ثابتوي چې چوکاټ قاعدې ته رسېدلی۔ همدا یوازې ثابتوي، نو رد شوې لاره هم تعقیب کړئ، ځکه هغه پالیسي چې هر څه مني هم خوځېدونکی شمېرښت پیدا کوي۔
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptچېرې چې زړ ماډل چلند بدلوي
په روان پل کې زړه لاره فعالول د لید زیاتولو بېطرفه کړنه نه ده۔ هغه قواعد چې مخکې د پل ټرافیک لپاره نهرسېدونکي وو اوس رسېدونکي کېږي، په دې کې د بل انټرفېس لپاره لیکل شوې د هوسټ قاعدې هم شاملې دي، او په ip forward زنځیر کې د drop اصلي پالیسي ناڅاپه هغو چوکاټونو ته پلي کېدای شي چې مخکې بې لاس وهنې تېرېدل۔ په هغه هوسټ چې د همدې پل له لارې مدیریت کېږي، پایله د کونسل پرته بندېدل دي۔ دا فرضي ناکامي حالت نه دی؛ دا د هغې ماشین پر هوکونو د ټولګې غځولو عادي پایله ده چې تاسو ورته د همدې نوې غځول شوې لارې له لارې رسېږئ۔
ډېره خوندي ترتیب دا دی چې پرېکړه وکړئ کومه کورنۍ د پالیسي مالکه ده، قاعدې هلته ولیکئ، او د هر sysctl له بدلولو مخکې خپلواکه د بیا رغېدو لاره وساتئ۔ که دوه کورنۍ دواړه قاعدې ولري، مستند کړئ کومه واکمنه ده؛ دوه پوښل شوې پالیسۍ هغه لاره ده چې بسته په یو ځای منل کېږي او په بل ځای غورځول کېږي، پرته له یوې لوستل کېدونکې فایل۔
جلاوالی پخپله اوس هم بشپړ ډیزاین ته اړتیا لري۔ یوې سرچینې ته د یو منزل اجازه ورکول یوازې دا ثابتوي چې یو بهیر کار کوي، خو اړتیا معمولاً دا ده چې VM خپلو ګاونډیانو یا هوسټ ته ونه رسېږي۔ د رد قاعدو شمېرښتونه د منلو قاعدې له شمېرښت څخه مهم دي، ځکه د منلو شمېرښت هغه دی چې تاسو مخکې تمه درلوده چې به خوځېږي۔
په پای کې، د هوسټ-ننوتلو پېښه جلا وساتئ۔ هغه ټرافیک چې د پل خپلې IP ته اړوند دی input ته رسېږي، forward ته نه، او په forward کې قاعده به یې هېڅکله ونه ویني، که کومه کورنۍ غوره کړئ۔ درې پېښې، دوه کورنۍ، یو درس: لاره هوک ټاکي، او هوک ټاکي چې ستاسو قاعده په اصل کې شته که نه۔