VPN پر Docker Swarm: ٹاسک چل رہے ہیں، سروس کالز ناکام ہو رہی ہیں

دونوں سائٹس پر ٹاسک چل رہے ہیں اور سروسز کے درمیان کالز وقت سے تجاوز کر رہی ہیں۔ overlay کو نوڈ سے نوڈ تک راستے، غیر ترجمہ شدہ پتے اور VXLAN کے لیے 50 بائٹ جگہ درکار ہے۔

دو سائٹس پر تین مینیجر اور پانچ ورکرز، ایک سرنگ سے جڑے ہوئے، اور docker service ls دونوں طرف چل رہے ٹاسک دکھا رہا ہے جبکہ سروسز کے درمیان کالز وقت سے تجاوز کر رہی ہیں۔ Swarm کے لاگز میں کچھ بھی غلط نہیں لگتا۔ یہ امتزاج ڈیٹا پلین مسئلے کی نشانی ہے: کنٹرول پلین نے نوڈز تلاش کر لیے، اور encapsulated فریموں نے سفر کبھی مکمل نہیں کیا۔

mesh کو overlay سے پہلے موجود ہونا چاہیے

Swarm کا overlay encapsulated فریموں کو براہ راست نوڈ پتوں کے درمیان دھکیلتا ہے، یعنی ہر نوڈ کو ایسا پتہ درکار ہے جہاں ہر دوسرا نوڈ بغیر ترجمے پہنچ سکے، اس انٹرفیس پر جو سرنگ فراہم کرتی ہے۔ صرف کلائنٹس کو شائع شدہ پورٹ تک لے جانے والی سرنگ کافی نہیں۔ نچلی تہہ کو دونوں سمتوں میں نوڈ سے نوڈ تک راستہ بنانا ہوگا۔

Swarm کو چھونے سے پہلے یہ جانچیں۔ ہر نوڈ سے ساتھی کے سرنگ پتے تک راستہ دیکھیں، اسے ping کریں، اور پھر کنٹرول پورٹ جانچیں۔ اگر ping چلے اور پورٹ نہ چلے تو سرنگ ٹھیک ہے اور راستے میں کوئی فلٹر ہے۔

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

اگر راستہ tun0 یا wg0 کے بجائے فزیکل انٹرفیس کی طرف اشارہ کرے تو overlay ایسے پتے پر encapsulate کرے گا جہاں دور کی سائٹ نہیں پہنچ سکتی، اور علامت پیکٹ کے ضیاع جیسی دکھے گی۔

دیکھیں کہ ہر نوڈ کون سا پتہ اعلان کرتا ہے

ڈیمن ایک پتہ اعلان کرتا ہے، اور ساتھی اسے ڈیٹا پلین کے لیے استعمال کرتے ہیں۔ متعدد نیٹ ورکس والے ہوسٹ پر LAN یا عوامی پتہ اعلان کرنا آسان ہے جبکہ سرنگ کچھ اور لے جا رہی ہو۔ اندازے کے بجائے اس کا معائنہ کریں، اور ڈیفالٹ غلط ہونے پر شامل ہوتے وقت --advertise-addr سے اسے پن کریں۔ جو نوڈ صرف اپنی رسائی کے پتے کا اعلان کرے وہ بھی swarm میں شامل ہو جاتا ہے، اور ناکامی بعد میں سائٹس کے درمیان بات نہ کر سکنے والی سروسز کے طور پر ظاہر ہوتی ہے۔

اعلان شدہ پتہ بعد میں بدلنا کنفیگ میں ترمیم نہیں ہے، کیونکہ نوڈ کو نکل کر دوبارہ شامل ہونا پڑتا ہے۔

ہر نوڈ کا اعلان شدہ پتہ اپنے نوٹس میں لکھیں، کیونکہ یہ زیادہ تر غیر متوازن ناکامیوں کی وضاحت کرتا ہے۔

Masquerade ہی عام مجرم ہے

جب نوڈز اور سرنگ کے درمیان گیٹ وے ہو، تو عام غلطی فزیکل انٹرفیس سے نکلنے والی ہر چیز پر masquerade لگانا ہے۔ یہ overlay کے اندرونی پتوں کو بھی دوبارہ لکھتا ہے، اس لیے ہر ساتھی گیٹ وے سے آیا ہوا دکھتا ہے اور VXLAN ساتھی ایک دوسرے کو پہچاننا چھوڑ دیتے ہیں۔ نتیجہ گمشدہ یا یک طرفہ encapsulated ٹریفک ہے جبکہ عام ping اب بھی چل رہے ہیں۔

overlay کا سابقہ گیٹ وے کے ذریعے روٹ کریں اور اسے غیر ترجمہ شدہ چھوڑ دیں۔ اگر کسی دوسرے سابقے کے لیے ترجمہ واقعی ضروری ہو تو اسے وہیں محدود رکھیں اور overlay کی استعمال کردہ حد پر کبھی نہیں۔

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

قواعد کی ترتیب اور متن دونوں جانچیں، کیونکہ زنجیر میں پہلے والا وسیع MASQUERADE بعد والی تنگ استثنا کو ہرا دیتا ہے۔

VXLAN کو پیکٹ میں جگہ درکار ہے

VXLAN اپنے لے جانے والے فریموں میں 50 بائٹ کا اضافہ کرتا ہے۔ 1500 بائٹ کی نچلی تہہ جب 1500 بائٹ کا اندرونی فریم لے جاتی ہے تو ایسا encapsulated پیکٹ بنتا ہے جسے کوئی راستہ نہیں پہنچائے گا، اور ناکامی سائز کے مسئلے کے بجائے وقفے وقفے سے سروس کی دریافت جیسی لگتی ہے۔ یا تو دونوں سروں پر سرنگ کا MTU کم کریں یا overlay کا MTU ایسا مقرر کریں کہ ڈرائیور فٹ ہونے والا پے لوڈ اعلان کرے۔

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

ingress نیٹ ورک خودبخود بنتا ہے، اس لیے اسے بدلنے کا مطلب ہے ہٹا کر دوبارہ بنانا، نہ کہ موقع پر ترمیم کرنا۔

اگر آپ سرنگ کا صرف ایک رخ ٹھیک کریں تو چھوٹا MTU پھر بھی وہی رہتا ہے جو اہمیت رکھتا ہے۔

لاگز نہیں، ڈیٹا پلین دیکھیں

دونوں سروں پر VXLAN پورٹ کیپچر کریں۔ ایک طرف سے نکل کر دوسری طرف پہنچنے والے فریم یعنی نچلی تہہ ٹھیک ہے اور مسئلہ overlay کے اندر ہے۔ نکل کر کبھی نہ پہنچنے والے فریم یعنی راستہ یا فلٹر۔ بالکل نہ نکلنے والے فریم یعنی ماخذ پتہ غلط ہے۔

چند سیکنڈ بعد مٹ جانے والی سروس کی دریافت کی ناکامیاں عام طور پر پیکٹ بجٹ یا ڈگمگاتے راستے کی طرف اشارہ کرتی ہیں، raft کورم کی طرف نہیں۔

چلتی ہوئی ونڈو کا کیپچر رکھیں، کیونکہ اس کا ٹوٹے ہوئے سے موازنہ کنفیگ دوبارہ پڑھنے سے تیز ہے۔

متعلقہ مضامین