ولې ستاسو VPN هغه وخت قطع کېږي چې Wi-Fi بدل شي یا Ethernet وتړل شي
'نوی SSID، د لاسرسي نقطو ترمنځ ګرځېدل او یو وتړل شوی کیبل ټونل په درې بېلابېلو ځایونو کې ماتوي۔ د سرچینې پته، بیا لاره، بیا پروتوکول وګورئ۔'
دوه شیان د یوې خرابۍ په توګه راپور کېږي: لپټاپ بل Wi-Fi شبکې ته تللی، یا کیبل هغه مهال وتړل شو چې Wi-Fi روان و۔ کلاینت لا هم وایي وتړل شوی، آیکون روغ ښکاري، او ټونل هېڅ نه وړي۔ د سطحې لاندې یوازې درې حالت ټوټې ښویېدلی شي - اړیکه، سیمهایزه پته، اصلي لاره - او کومه یې ښویېدلې دا پرېکړه کوي چې ټونل پخپله روغېږي که بیا وتړل کېدو ته اړتیا لري۔ زه دوی همدې ترتیب ته ګورم، ځکه چې د حساب تنظیماتو بدلول له دوی څخه یو هم کله هم نه دی سم کړی۔
اړیکه، پته او لاره په خپلواک ډول ښویېږي
په یوه شبکه کې د لاسرسي نقطو ترمنځ ګرځېدل معمولاً L2 پېښه ده۔ راډیو بیا یوځای کېږي، انټرفیس خپله پته او ګېټوې ساتي، او هغه څه چې ټونل پرې تکیه ده بدلېږي نه، له همدې امله په لوی دفتر کې تګ ځینې وخت له پامه وتلی وي۔ بل SSID ته ننوتل دا نه دي: زوړ انټرفیس کېدای شي ښکته شي، DHCP نوې پته، نوی ګېټوې او نوي حل کوونکي ورکوي، او هغه بهرنی بهیر چې ټونل یې کاراوه نور نه وي۔
Ethernet درېیمه بڼه ورزیاتوي۔ Wi-Fi کله هم نه لوېږي، نو د اړیکې پېښه هیڅ نه پېښېږي، خو تار لرونکی انټرفیس خپله پته سره ښکاري او ډېری وخت د مېټریک له مخې اصلي لاره ګټي۔ ټونل هغه لارې ته دوام ورکوي چې نوره غوره نه ده، یا کلاینت خپل ساکټ هغه بېتاره شبکې ته نښلولی ساتي چې پکې یې پیل کړی و۔ له براوزره دواړه یو شان ښکاري: کیبل ناستې سره سم مخونه ودرېږي۔
نو لومړنۍ پوښتنه دا نه ده چې Wi-Fi بدل شو که نه۔ پوښتنه دا ده چې هغه پته چې تاسو پرې تړلي یاست، یا لاره تر پای ټکي، د ټونل د روانېدو پر مهال بدله شوه که نه۔
بهرنی ساکټ هغې پتې ته نښلول شوی چې همدا اوس ورک شوه
هر ټونل یو بهرنی بهیر دی: یوه سیمهایزه پته او پورټ د سرور پتې او پورټ سره خبرې کوي۔ په Linux کې دا زوړ سرچینې ته تړل شوی UDP ساکټ دی؛ کله چې پته لرونکی انټرفیس لرې شي، لېږنې یا د EADDRNOTAVAIL سره ناکامېږي یا له نوي انټرفیس څخه د هغې سرچینې سره وځي چې سرور کله هم نه ده لیدلې۔
لرې خوا خپله نښلون ساتي۔ پرته له MOBIKE د IKEv2 SA د پتو جوړې په واسطه پېژندل کېږي، او یو OpenVPN ناسته هغې سیالې پتې ته تړلې وي چې زده کړې یې ده، او NAT نقشه هغې خصوصي پتې، پورټ او عامې پتې پورې اړه لري چې جوړه کړې یې ده۔ بل NAT ته لاړ شئ او هر ځواب هغې نقشې ته ځي چې نوره نشته۔ ستاسو په ماشین کې هېڅ غلط تنظیم شوی نه دی؛ پنځهګون هغې شبکې ته اشاره کوي چې پرېښودله۔
له تیورۍ جوړولو مخکې حالت ولولئ:
ss -unpهغه سیمهایزه پته او پورټ ښیي چې هر ټونل ساکټ یې واقعاً لري۔ip route get 203.0.113.10هغه سرچینه پته او وسیله چاپوي چې کرنل به یې اوس د پای ټکي لپاره کاروي۔wg show wg0 endpoints،swanctl --list-sasیا د کلاینت لاګ هغه سیاله پته ښیي چې لرې خوا فکر کوي ورسره خبرې کوي۔
که د ساکټ پته او د لارې پلټنه سره سمون نه لري، تاسو ماتېدل موندلي او هېڅ د اعتبارنامې بدلون به ورته لاس ونه وړي۔
هر پروتوکول له نوې سرچینه پتې سره څه کوي
کلاینتونه بدلون په بېلابېلو کچو جذبوي، او جدول هغه څه دي چې زه یې د کلاینت ترتیب سره پرتله کوم، د بیا وتړلو چلند څخه د اټکل کولو پرځای۔
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
د WireGuard د ګرځېدو قاعده یوازې یوې خوا ته کار کوي: کلاینت باید لومړی له نوې پتې ولېږي۔ هغه ساکټ چې لا هم زوړ انټرفیس ته تړلی وي دا کله هم نه کوي، له همدې امله ټونل ژوندی ښکاري خو د لاس ورکولو ټایمر یې زوړېږي۔ د پروتوکول تشریح د پای ټکي د تازه کولو شرط په دقت سره بیانوي، او له ترتیب بدلولو مخکې یې لوستل ارزښت لري۔
MOBIKE د خبرو اترو له لارې ټاکل کېږي، اټکل نه کېږي۔ که سرور یې وړاندې نه کړي، کلاینت باید بیا جوړ کړي، او دا هغه حقیقت دی چې له SA لیست یا لاګ څخه یې تاییدوئ، نه له څرخېدونکي څرخ څخه یې استنباطوئ۔
لاره د مسیر لومړیتوب ټاکي، نه د Wi-Fi آیکون
کله چې دواړه انټرفیسونه پورته وي، کرنل د مېټریک او مخکښ اوږدوالي له مخې غوره کوي۔ ip route show default نوماندان لیستوي او ip route get 203.0.113.10 د سرچینې پتې په شمول ریښتینی پرېکړه حل کوي۔ په مېټریک 100 تار لرونکی اصلي او په 600 بېتار یعنی پای ټکی هغه ساه چې کیبل ناست شي ښویېږي، پداسې حال کې چې هر هغه اپلیکیشن چې مخکې ساکټ پرانیستی خپله زوړه سرچینه ساتي۔
Windows هم د اتوماتیک انټرفیس مېټریک سره همدا کوي، د اړیکې سرعت له مخې تعصب لري۔ Get-NetRoute -DestinationPrefix 0.0.0.0/0 نوماندان ترتیبوي او Find-NetRoute -RemoteIPAddress 203.0.113.10 هغه انټرفیس او سرچینه بېرته راګرځوي چې سټک به غوره کړي۔ هغه کلاینت چې بهرنی ساکټ یې یو انټرفیس ته تړلی وي د مېټریک له اوښتلو وروسته هم هغه کاروي؛ دا د تړلو پرېکړه ده، د لارښوونې خرابي نه ده۔
Android بېلګېدل ښکاره کوي: ConnectivityManager شته شبکې او جلا اصلي راپور کوي، او هغه VPN اپلیکیشن چې ساکټ د Network شي ته تړي هغه تړل ساتي تر څو چې بیا یې وتړي۔ په macOS کې، scutil --nwi لومړنی انټرفیس او هغه ترتیب چاپوي چې سیستم به یې کاروي۔
DNS، MTU او IPv6 د نښلېدو سره ښویېږي
نوی نښلېدل نوي حل کوونکي راوړي۔ د systemd-resolved سره DNS د هرې اړیکې لپاره، resolvectl status ښیي چې کومه اړیکه نوم ته ځواب وایي، او هغه مېلمه شبکه چې خپل حل کوونکی شریکوي کېدای شي د ټونل ټېل وهلی DNS تر هغه چې اړیکه بیا غوره شي بېکاره پرېږدي۔ نیوونکی پورټل دا نور هم خرابوي: لومړنۍ HTTPS غوښتنې ته د پای ټکي پرځای پورټل ځواب وایي، او کلاینت مړ سرور ثبتوي۔
د لارې MTU هم بدلېږي۔ Ethernet او Wi-Fi معمولاً 1500 بایټ وړي، PPPoE 1492، او موبایل اړیکې ډېری لږ۔ هغه ټونل چې کوچنی MTU میراث واخلي په لویو پاکټونو کې ودرېږي خو کوچنۍ غوښتنې تېرېږي، چې دا نیمه ماتېدلې اړیکه لوستل کېږي۔ ping -M do -s 1472 203.0.113.10 1500 بایټیز پاکټ د DF سره لېږي؛ چوپتیا یعنې لاره ستاسو له اټکل څخه کوچنۍ ده۔
IPv6 بله نیمه ده۔ هغه شبکه چې نوی مخکښ ورکوي د دوهسټکیز کلاینت سرچینه بدلوي، او یوازې v4 ټونل v6 ترافیک تر هغه چې پالیسي ورسیږي بهر پرېږدي۔ ip -6 route show default او ip -6 addr show ځواب وایي چې نوې اړیکه اصلاً v6 لاره لري که نه۔
د تشریح کولو پرځای بدلون بیا تولید کړئ
یوه بېزیانه غوښتنه وټاکئ او د بدلون په دواړو خواو کې هغه درې حکمونه وچلوئ: ip -br addr، ip route show default، ip route get 203.0.113.10۔ بیا وګورئ چې ټونل لا هم پاکټونه باسي که نه - tcpdump -ni any udp port 51820 د WireGuard لپاره، د نورو هر څه لپاره سم پورټ۔ له زوړ سرچینې وتونکي پاکټونه د تړلو ستونزه مانا لري۔ له نوې سرچینې څخه بېځوابه وتونکي پاکټونه لرې خوا یا منځنی NAT مانا لري۔
یادداشت کړئ کومه پېښه له لومړنۍ خرابۍ سره یوځای شوه: د اړیکې لوېدل، د پتې بدلون، یا د اصلي لارې بدلون۔ دا بېلابېلو مسؤلینو ته اشاره کوي - هغه کلاینت چې بیا تړل غواړي، هغه پته چې بیا اخیستل غواړي، یا هغه لاره چې د ترتیب فایل پورې اړه لري نه دایمي تېښتې قاعدې ته۔
له سمې شوې ویلو مخکې تایید کړئ چې د مستقیم ترافیک بلاک د تشې پر مهال هم ټینګ دی او نومونه د نوې اړیکې له لارې حل کېږي۔ که له بدلون وروسته هم کلاینت زوړ پای ټکی ساتي، لومړی د ګرځېدو یا float تنظیم سم کړئ۔ که سم ګرځي او بیا هم ځواب نه اخلي، د سرور د سیال هویت او د لارې NAT وګورئ، او دواړه شبکهایز زمینه په راپور کې وساتئ تر څو بل کس یې پرتله کړي۔