Bi gauza hutsegite bakar gisa jakinarazten dira: ordenagailua beste Wi-Fi sare batera pasa da, edo kable bat konektatu da Wi-Fi martxan jarraitzen zuen bitartean. Bezeroak oraindik konektatuta dio, ikonoa osasuntsu dago, eta tuneletik ez da ezer pasatzen. Azpian hiru egoera-zati baino ezin dira mugitu - esteka, helbide lokala, defektuzko ibilbidea - eta zein mugitu den erabakitzen du tunela bere kabuz berreskuratuko den edo berriz konektatu behar duen. Hori ordena horretan egiaztatzen dut, kontu-ezarpenak aldatzeak ez baitu inoiz horietako bat konpondu.

Esteka, helbidea eta ibilbidea modu independentean mugitzen dira

Sare bereko sarbide-puntuen arteko ibiltaritza L2 gertaera izaten da normalean. Irratiak berriz elkartzen du, interfazeak bere helbidea eta atebidea mantentzen ditu, eta tunelak dependatzen duen ezerk ez du aldatzen; horregatik, bulego handi bat zeharkatzeak batzuetan oharkabean egiten du. Beste SSID batera batzea ez da hori: interfaze zaharrak behera egin dezake, DHCPk helbide berri bat, atebide berri bat eta resolver berriak ematen ditu, eta tunelak erabiltzen zuen kanpoko fluxua existitzeari uzten dio.

Ethernetek hirugarren forma gehitzen du. Wi-Fi ez da inoiz erortzen, beraz ez da esteka-gertaerarik pizten, baina kablezko interfazea bere helbidearekin agertzen da eta askotan defektuzko ibilbidea irabazten du metrikagatik. Tunelak jada hobetsia ez den bide batetik jarraitzen du, edo bezeroak socket-a hasi zen haririk gabeko sarera lotuta mantentzen du. Nabigatzailetik biak berdin ikusten dira: orrialdeak trabatzen dira kablea sartzen den unean.

Beraz, lehen galdera ez da ea Wi-Fi aldatu den. Galdera da ea lotuta zauden helbidea, edo helmugarako ibilbidea, aldatu den tunela martxan zegoela.

Kanpoko socket-a oraintxe desagertu den helbide batera lotuta dago

Tunel bakoitza kanpoko fluxu bat da: zerbitzariaren helbide eta ataka mintzatzen dituen helbide eta ataka lokalak. Linuxen hori iturburu zaharrari lotuta dagoen UDP socket bat da; helbidea duen interfazea kentzen denean, bidalketek EADDRNOTAVAIL-ekin huts egiten dute edo interfaze berritik irteten dira zerbitzariak inoiz ikusi ez duen iturburu batekin.

Urrutiko aldeak bere esteka mantentzen du. MOBIKE gabe IKEv2 SA bat helbide-bikoteak identifikatzen du, eta OpenVPN saio bat ikasi duen parearen helbidera lotuta dago, eta NAT mapaketa bat sortu zuen helbide pribatu, ataka eta helbide publikotara dagokio. Mugitu beste NAT baten atzera eta erantzun bakoitza jada existitzen ez den mapaketara bidaltzen da. Zure makinan ez dago ezer oker konfiguratuta; boskotea utzi duzun sare batera seinalatzen du.

Irakurri egoera teorizatu aurretik:

  • ss -unp tunel-socket bakoitzak benetan duen helbide eta ataka lokalak erakusten ditu.
  • ip route get 203.0.113.10 kernelek oraintxe helmugarako erabiliko lukeen iturburu-helbidea eta gailua inprimatzen ditu.
  • wg show wg0 endpoints, swanctl --list-sas edo bezeroaren erregistroak urrutiko aldeak hitz egiten ari dela uste duen parearen helbidea erakusten du.

Socket-aren helbidea eta ibilbide-kontsulta bat ez badatoz, haustea aurkitu duzu, eta kredentzialen aldaketak ez du hori ukituko.

Zer egiten duen protokolo bakoitzak iturburu-helbide berri batekin

Bezeroek aldaketa maila desberdinetan xurgatzen dute, eta taula da bezeroaren konfigurazioarekin alderatzen dudana, berriz konektatzeko jokabidetik asmatu beharrean.

TunnelRecovery behaviourFailure signature
WireGuardUpdates 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/IPsecMOBIKE (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 TCPThe tunnel is a byte stream, so a changed source address breaks it outright.Immediate reset and a new connection attempt.

WireGuarden ibiltaritza-arauak norabide bakarrean baino ez du funtzionatzen: bezeroak lehenengo helbide berritik bidali behar du. Interfaze zaharrari lotuta dagoen socket-ak inoiz ez du hori egiten, eta horregatik tunelak bizirik izan dezake eskuko keinuaren tenporizadorea zahartzen ari den bitartean. protokoloaren deskribapena helmugaren eguneratze-baldintza zehazki ezartzen du, eta merezi du konfigurazio bat aldatu aurretik irakurtzea.

MOBIKE negoziatu egiten da, ez da suposatzen. Zerbitzariak eskaintzen ez badu, bezeroak berrezarri behar du, eta hori SA zerrendatik edo erregistrotik baieztatzen duzun egitatea da, ez biraka ari den gurpil batetik ondorioztatzen duzuna.

Ibilbide-hobespenak erabakitzen du bidea, ez Wi-Fi ikonoak

Bi interfazeak gorago daudela, kernelek metrika eta aurrizki-luzeraren arabera aukeratzen du. ip route show default hautagaien zerrenda ematen du eta ip route get 203.0.113.10 benetako erabakia ebazten du, iturburu-helbidea barne. Metrika 100eko kablezko defektuzko batek eta 600ko haririk gabeko batek esan nahi dute helmuga kablea esertzen den unean mugitzen dela, eta, bitartean, lehenago socket bat ireki zuen aplikazio bakoitzak bere iturburu zaharra mantentzen duela.

Windowsek gauza bera egiten du interfaze-metrika automatikoekin, estekak duen abiadurak alboratuta. Get-NetRoute -DestinationPrefix 0.0.0.0/0 hautagaiak ordenatzen ditu eta Find-NetRoute -RemoteIPAddress 203.0.113.10 pilak aukeratuko lukeen interfazea eta iturburua itzultzen ditu. Kanpoko socket-a interfaze bakarrari lotzen dion bezeroak hura erabiltzen jarraitzen du metrika aldatu ondoren; hori lotze-erabakia da, ez ibilbide-hutsegitea.

Androidek banaketa ikusgarri egiten du: ConnectivityManagerek sare eskuragarriak eta defektuzko bereizi bat jakinarazten ditu, eta socket bat Network objektu batera lotzen duen VPN aplikazioak lotura hori mantentzen du berriz lotu arte. macOSen, scutil --nwi interfaze nagusia eta sistemak erabiliko lukeen ordena inprimatzen ditu.

DNS, MTU eta IPv6 atxikimenduarekin batera mugitzen dira

Atxikimendu berri batek resolver berriak ekartzen ditu. systemd-resolvedekin DNS esteka bakoitzeko da, resolvectl status zein estekak izen bati erantzuten dion erakusten du, eta bere resolver propioa banatzen duen gonbidatu-sare batek tunelak bultzatutako DNS erabili gabe utz dezake esteka berriz hobetsi arte. Atxilotze-portalak okerrera egiten du: lehen HTTPS eskaerari portalak erantzuten dio, ez helmugak, eta bezeroak zerbitzari hil bat erregistratzen du.

Bidearen MTU ere aldatzen da. Ethernetek eta Wi-Fik normalean 1500 byte eramaten dituzte, PPPoE-k 1492, eta mugikor-estekek sarritan gutxiago. MTU txikiagoa heredatzen duen tunel bat pakete handietan trabatzen da eskaera txikiak arrakastatsuak diren bitartean, eta hori erdi hautsitako konexio gisa irakurtzen da. ping -M do -s 1472 203.0.113.10 DF ezarrita duen 1500 byteko paketea bidaltzen du; isiltasunak bidea uste baino txikiagoa dela esan nahi du.

IPv6 da beste erdia. Aurrizki berri bat ematen duen sare batek pila bikoitzeko bezero batek erabiliko lukeen iturburua aldatzen du, eta v4 soilik den tunel batek v6 trafikoa kanpoan uzten du politika harrapatu arte. ip -6 route show default eta ip -6 addr show erantzuten dute esteka berriak v6 biderik duen ala ez.

Erreproduzitu trantsizioa deskribatu beharrean

Aukeratu eskaera kaltegabe bat eta exekutatu hiru komando berak aldaketaren bi aldeetan: ip -br addr, ip route show default, ip route get 203.0.113.10. Ondoren begiratu tunelak oraindik paketeak igortzen dituen - tcpdump -ni any udp port 51820 WireGuardentzat, beste edozertarako ataka dagokiona. Iturburu zaharretik irteten diren paketeek lotze-arazoa esan nahi dute. Iturburu berritik erantzunik gabe irteten diren paketeek urrutiko aldea edo erdiko NATa esan nahi dute.

Idatzi zein gertaera bat etorri zen lehen hutsegitearekin: esteka behera, helbide-aldaketa edo defektuzko ibilbidearen aldaketa. Hauek jabe desberdinetara seinalatzen dute - berriz lotu behar duen bezeroa, berriz eskuratu behar den helbidea, edo konfigurazio-fitxategi bati dagokion ibilbidea eta ez betiko saihesteko arauari.

Konpondutzat eman aurretik, egiaztatu zuzeneko trafikoaren blokeak hutsunean zehar eusten duela eta izenak atxikimendu berritik ebazten direla. Bezeroak aldaketa ondoren helmuga zaharra mantentzen badu, konpondu lehenik ibiltaritza edo float ezarpena. Behar bezala ibiltzen bada eta oraindik erantzunik jasotzen ez badu, begiratu zerbitzariaren parearen identitatea eta bideko NATa, eta gorde bi sare-kontestuak idazkian hurrengo pertsonak alderatu ahal izan ditzan.

Erlazionatutako artikuluak