انتشار یک سرویس LAN روی نشانی خود دروازه VPN

نمایش یک دستگاه LAN روی یکی از نشانی‌های تونل خود دروازه تنها به یک خط NAT نیاز دارد. با این حال اتصال شکست می‌خورد، چون دستگاهی که پاسخ می‌دهد هیچ نمی‌داند که نشانی کلاینت از طریق همان دروازه قابل دسترسی است. بسته را از کلاینت به سمت داخل دنبال کنید، سپس پاسخ را به سمت بیرون دنبال کنید، و نیمه گمشده آشکار می‌شود.

از دید کلاینت شروع کنید

کلاینت در این مثال در استخر VPN 10.62.0.0/24 قرار دارد و روی درگاه 8080 به 10.62.0.1 متصل می‌شود. آن نشانی متعلق به خود دروازه است، بنابراین بسته به هسته دروازه می‌رسد نه به همتای دیگر. پشت دروازه، شبکه محلی 172.21.4.0/24 است. دروازه 172.21.4.10 را دارد و دستگاهی که واقعاً HTTP سرویس می‌دهد 172.21.4.40 است.

نشانی متعلق به همتای دیگر VPN با نشانی سرویس دروازه قابل تعویض نیست. اگر کلاینت به نشانی یک همتا متصل شود، هیچ قاعده‌ای از دروازه دخیل نیست و این کل بررسی برای مورد اشتباه است.

دامنه ترجمه مقصد را آگاهانه محدود کنید

نسخه باریک یک درگاه را نمایش می‌دهد و فقط مقصد را بازنویسی می‌کند. بسته پروتکل و مبدأ خود را نگه می‌دارد و همین است که بقیه مسیر را جالب می‌کند.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

قاعده‌ای بدون معیار پروتکل و درگاه نسخه گسترده است: هر درگاهی را که کلاینت انتخاب کرده حفظ می‌کند و تنها نشانی را تغییر می‌دهد. این وقتی مشروع است که کل میزبان نمایش داده شود، و وقتی نادرست است که یک سرویس مقصود بوده. قاعده را دوباره بخوانید و نام رابط را تأیید کنید. قاعده DNAT روی رابط اشتباه با هیچ چیز مطابقت ندارد، که همان مهلت قاعده گمشده را تولید می‌کند و یک ساعت نگاه کردن به دستگاه را تلف می‌کند.

بگذارید مرز فوروارد هم‌نظر شود

ترجمه سرآیند را تغییر می‌دهد، اما اجازه نمی‌دهد. با سیاست رد پیش‌فرض، جریان فورواردشده به پذیرش خودش نیاز دارد و جهت بازگشت به قاعده اتصال برقرار که سیاست شما احتمالاً از قبل دارد.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

پذیرش بی‌قید برای هر جریان DNAT گسترده‌تر از این طراحی است و نگاشت‌هایی را هم اجازه می‌دهد که بعداً کس دیگری اضافه می‌کند. مقصد و درگاه را نام ببرید و بقیه را بسته بگذارید. اگر شمارنده‌های قاعده فوروارد صفر بمانند در حالی که شمارنده‌های NAT بالا می‌روند، بسته پیش از قاعده شما دور ریخته می‌شود. ترتیب زنجیره را بخوانید نه اینکه نسخه دومی اضافه کنید.

دستگاه باید به نحوی پاسخ دهد

پس از ترجمه، دستگاه مبدأیی در 10.62.0.0/24 می‌بیند. پاسخش به دروازه پیش‌فرض خودش می‌رود، که همان مسیریاب شبکه محلی است نه دروازه VPN، مگر اینکه چیزی خلاف آن را بگوید. دو ترتیب این را درست می‌کند و هم‌ارز نیستند. یک مسیر روی دستگاه یا روی مسیریاب شبکه محلی، 10.62.0.0/24 را به 172.21.4.10 می‌فرستد و مبدأ کلاینت را حفظ می‌کند. ترجمه مبدأ محدود به جای آن کلاینت را پشت نشانی شبکه محلی دروازه پنهان می‌کند.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

بر اساس آنچه سرویس نیاز دارد انتخاب کنید. سیاست به‌ازای هر کلاینت و گزارش‌های معنادار شکل مسیریابی‌شده را می‌خواهند؛ دستگاهی که نمی‌توان به آن مسیر داد، یا سرویسی که باید نشانی شبکه محلی را ببیند، به شکل ترجمه‌شده اشاره می‌کنند. برای کار کردن یک پاسخ به سراغ قاعده masquerade سراسری نروید. این قاعده هر کلاینت را از هر مقصد پنهان می‌کند و سیاست‌هایی را که به نشانی مبدأ وابسته‌اند بی‌صدا می‌شکند.

از خود دروازه آزمایش نکنید

درخواستی که روی دروازه به 10.62.0.1 ساخته می‌شود از زنجیره OUTPUT بیرون می‌رود، نه از PREROUTING ورودی. شکست یا موفقیت آن چیزی درباره قاعده رو به کلاینت نمی‌گوید، و این‌گونه است که مردم نتیجه می‌گیرند قاعده‌ای که کار می‌کند خراب است.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

یک درخواست واقعی کلاینت اجرا کنید و هر دو را بخوانید. ورودی conntrack ترجمه اعمال‌شده را نشان می‌دهد و ضبط‌ها نشان می‌دهند که درخواست به شبکه محلی گذشته و پاسخی به سمت تونل بازگشته یا نه. پس از تغییر قاعده‌ها از اتصال تازه استفاده کنید، چون وضعیت موجود نگاشت پیشین خود را حفظ می‌کند و به روش قدیمی شکست می‌خورد. سپس کل گفت‌وگو را تأیید کنید: نشانی دستگاه، اجازه فوروارد و مسیر پاسخ همه یک جریان را توصیف می‌کنند.