Kwa nini VPN yako inakatika Wi-Fi inapobadilika au Ethernet inapochomekwa

Mambo mawili huripotiwa kama hitilafu moja: kompyuta imehamia mtandao mwingine wa Wi-Fi, au kebo ilichomekwa wakati Wi-Fi ikiendelea kufanya kazi. Mteja bado anasema ameunganishwa, aikoni inaonekana nzuri, na handaki haibebi chochote. Chini ya uso, sehemu tatu tu za hali zinaweza kusogea - muunganisho, anwani ya ndani, njia chaguo-msingi - na ipi iliyosogea ndiyo huamua kama handaki itajirekebisha yenyewe au inahitaji kuunganishwa upya. Ninaziangalia kwa mpangilio huo, kwa sababu kubadilisha mipangilio ya akaunti hakujawahi kurekebisha hata moja.

Muunganisho, anwani na njia husogea kwa kujitegemea

Uhamishaji kati ya vituo vya ufikiaji vya mtandao mmoja kwa kawaida ni tukio la L2. Redio hujiunga upya, kiolesura hudumisha anwani na lango lake, na hakuna kinachotegemea handaki kinachobadilika, ndiyo sababu kutembea katika ofisi kubwa wakati mwingine hupita bila kutambuliwa. Kujiunga na SSID nyingine si hivyo: kiolesura cha zamani kinaweza kuanguka, DHCP inatoa anwani mpya, lango jipya na vitatuzi vipya, na mtiririko wa nje ambao handaki ilitumia hautakuwepo tena.

Ethernet inaongeza umbo la tatu. Wi-Fi haianguki kamwe, kwa hiyo hakuna tukio la muunganisho linaloanzishwa kabisa, lakini kiolesura cha waya kinaonekana na anwani yake mwenyewe na mara nyingi hushinda njia chaguo-msingi kwa metriki. Handaki inaendelea kwenye njia ambayo haipendelewi tena, au mteja hushikilia soketi yake imefungwa kwenye mtandao usio na waya ambao uliianza. Kutoka kwa kivinjari vyote viwili vinaonekana sawa: kurasa zinasimama mara tu kebo inapokaa.

Kwa hiyo swali la kwanza si kama Wi-Fi ilibadilika. Ni kama anwani uliyofungwa nayo, au njia hadi kituo cha mwisho, ilibadilika wakati handaki ikiwa hai.

Soketi ya nje imefungwa kwenye anwani iliyotoweka sasa hivi

Kila handaki ni mtiririko wa nje: anwani na bandari za ndani zinazozungumza na anwani na bandari za seva. Kwenye Linux hiyo ni soketi ya UDP iliyofungwa kwenye chanzo cha zamani; kiolesura kinachoshikilia anwani kinapoondolewa, utumaji hushindwa kwa EADDRNOTAVAIL au hutoka kupitia kiolesura kipya na chanzo ambacho seva haijawahi kuona.

Upande wa mbali huhifadhi kifungo chake. SA ya IKEv2 bila MOBIKE hutambuliwa kwa jozi ya anwani, na OpenVPN kipindi hufungwa kwa anwani ya mwenzake iliyojifunza, na ramani ya NAT ni ya anwani ya faragha, bandari na anwani ya umma zilizoiumba. Nenda nyuma ya NAT nyingine na kila jibu huenda kwenye ramani ambayo haipo tena. Hakuna kilichowekwa vibaya kwenye mashine yako; tano-tuple inaelekeza kwenye mtandao uliouacha.

Soma hali kabla ya kufanya nadharia:

• ss -unp huonyesha anwani na bandari za ndani ambazo kila soketi ya handaki inashikilia kweli.
• ip route get 203.0.113.10 huchapisha anwani ya chanzo na kifaa ambacho kerneli ingetumia kwa kituo cha mwisho sasa hivi.
• wg show wg0 endpoints, swanctl --list-sas au kumbukumbu ya mteja huonyesha anwani ya mwenzake ambaye upande wa mbali unadhani unazungumza naye.

Ikiwa anwani ya soketi na utafutaji wa njia hazikubaliani, umepata mpasuko, na hakuna mabadiliko ya vitambulisho yatakaoigusa.

Kila itifaki hufanya nini na anwani mpya ya chanzo

Wateja hunyonya mabadiliko kwa viwango tofauti, na jedwali ndilo ninalolinganisha na usanidi wa mteja badala ya kukisia kutokana na tabia ya kuunganisha upya.

Kanuni ya uhamishaji ya WireGuard inafanya kazi upande mmoja tu: mteja lazima atume kwanza kutoka anwani mpya. Soketi iliyofungwa bado kwenye kiolesura cha zamani haifanyi hivyo kamwe, ndiyo sababu handaki inaweza kuonekana hai wakati kipima muda cha kupeana mikono kinazeeka. maelezo ya itifaki yanaeleza kwa usahihi sharti la kusasisha kituo cha mwisho, na inafaa kusoma kabla ya kubadilisha usanidi.

MOBIKE hujadiliwa, haidhaniwi. Ikiwa seva haitoi, mteja lazima aanzishe upya, na hiyo ni ukweli unaouthibitisha kutoka orodha ya SA au kumbukumbu, si kitu unachokisia kutoka kwa gurudumu linalozunguka.

Njia huamuliwa na kipaumbele cha njia, si aikoni ya Wi-Fi

Wakati violesura vyote viwili viko juu, kerneli huchagua kwa metriki na urefu wa kiambishi awali. ip route show default huorodhesha watahiniwa na ip route get 203.0.113.10 hutatua uamuzi halisi, ikiwa ni pamoja na anwani ya chanzo. Njia chaguo-msingi ya waya kwa metriki 100 na isiyo na waya kwa 600 zinamaanisha kituo cha mwisho husogea mara tu kebo inapokaa, wakati kila programu iliyofungua soketi mapema huhifadhi chanzo chake cha zamani.

Windows hufanya vivyo hivyo kwa metriki za kiolesura otomatiki, zilizopendelea kwa kasi ya muunganisho. Get-NetRoute -DestinationPrefix 0.0.0.0/0 hupanga watahiniwa na Find-NetRoute -RemoteIPAddress 203.0.113.10 hurudisha kiolesura na chanzo ambacho staki ingechagua. Mteja anayefunga soketi yake ya nje kwenye kiolesura kimoja huendelea kuitumia baada ya metriki kupinduka; huo ni uamuzi wa kufunga, si hitilafu ya uelekezaji.

Android hufanya mgawanyiko uonekane: ConnectivityManager huripoti mitandao inayopatikana na chaguo-msingi tofauti, na programu ya VPN inayofunga soketi kwenye kitu cha Network hudumisha kifungo hicho hadi ifunge upya. Kwenye macOS, scutil --nwi huchapisha kiolesura cha msingi na mpangilio ambao mfumo ungetumia.

DNS, MTU na IPv6 husogea pamoja na muunganisho

Muunganisho mpya huleta vitatuzi vipya. Kwa systemd-resolved DNS ni kwa kila muunganisho, resolvectl status huonyesha muunganisho upi unajibu jina, na mtandao wa wageni unaogawanya kitatuzi chake unaweza kuacha DNS iliyosukumwa na handaki bila kutumika hadi muunganisho upendelewe tena. Lango linalokamata huifanya kuwa mbaya zaidi: ombi la kwanza la HTTPS hujibiwa na lango badala ya kituo cha mwisho, na mteja hurekodi seva iliyokufa.

MTU ya njia pia hubadilika. Ethernet na Wi-Fi kwa kawaida hubeba baiti 1500, PPPoE 1492, na viungo vya simu mara nyingi chini zaidi. Handaki inayorithi MTU ndogo hukwama kwenye pakiti kubwa wakati maombi madogo hupita, ambayo husomwa kama muunganisho uliovunjika nusu. ping -M do -s 1472 203.0.113.10 hutuma pakiti ya baiti 1500 ikiwa DF imewekwa; ukimya unamaanisha njia ni ndogo kuliko ulivyodhani.

IPv6 ni nusu nyingine. Mtandao unaotoa kiambishi awali kipya hubadilisha chanzo ambacho mteja wa staki mbili angetumia, na handaki ya v4 pekee huacha trafiki ya v6 nje hadi sera ifikie. ip -6 route show default na ip -6 addr show hujibu kama muunganisho mpya una njia ya v6 kabisa.

Zalisha upya mpito badala ya kuueleza

Chagua ombi moja lisilo na madhara na uendeshe amri tatu zilezile pande zote za mabadiliko: ip -br addr, ip route show default, ip route get 203.0.113.10. Kisha angalia kama handaki bado inatoa pakiti - tcpdump -ni any udp port 51820 kwa WireGuard, bandari inayolingana kwa kila kitu kingine. Pakiti zinazotoka kwenye chanzo cha zamani zinamaanisha tatizo la kufunga. Pakiti kutoka chanzo kipya bila jibu zinamaanisha upande wa mbali au NAT iliyo katikati.

Kumbuka ni tukio gani liliendana na hitilafu ya kwanza: muunganisho kuanguka, anwani kubadilika, au njia chaguo-msingi kubadilika. Hivi huelekeza kwa wamiliki tofauti - mteja anayehitaji kufungwa upya, anwani inayohitaji kupatikana upya, au njia inayomilikiwa na faili ya usanidi na si kanuni ya kudumu ya kupita kando.

Kabla ya kusema imerekebishwa, thibitisha kwamba kizuizi cha trafiki ya moja kwa moja bado kinastahimili wakati wa pengo na kwamba majina hutatuliwa kupitia muunganisho mpya. Ikiwa mteja anashikilia kituo cha mwisho cha zamani baada ya kubadilisha, rekebisha kwanza mpangilio wa uhamishaji au float. Ikiwa unahama kwa usahihi na bado haupati jibu, angalia utambulisho wa mwenzake kwenye seva na NAT kwenye njia, na uweke muktadha wote wa mtandao kwenye ripoti ili mtu anayefuata aweze kulinganisha.