VPN-biðlari á LAN-þjóni: hvers vegna svör fara rangar leiðir

Einkennin fylgja einu mynstri: hýsill virkar, svo tengist hann VPN sem biðlari, og nú ná LAN-biðlarar honum á meðan svör hans hverfa. Upptaka á hýslinum sýnir að svörin fara í gegnum gangtækið í stað LAN-tengisins. Ekkert er bilað í ganginum, og lagfæringin er leið, ekki endurtenging. Farðu í gegnum fjórar prófanirnar hér að neðan í röð og stöðvaðu við þá fyrstu sem bregst.

Svar er nýr pakki, ekki öfug leið

Það hjálpar að sleppa þeirri hugmynd að svar fer til baka eftir sömu leið og beiðni fór. Leiðsögn er ákveðin fyrir hverja pakka og hverja stefnu á sendandi hýsilnum. Beiðni sem barst frá 10.64.0.23 inni í ganginum býr ekki til neina bakleið; þegar hýsillinn svarar er það svar borið saman við töfluna sem nýr pakki og fer út um þá leið sem vinnur.

Þess vegna veldur biðlari með fullan gang á vél sem þjónar einnig LAN svo ruglingslegri bilun. Biðlarinn setur upp sjálfgefna leið, eða hálfar sjálfgefnu leiðirnar tvær sem sumir biðlarar kjósa, og svarið til LAN-biðlara passar nú við ganginn. Það fer til veitandans, sem hefur enga ástæðu til að senda það áfram, og LAN-biðlarinn sér tímaútrennsli þótt hýsillinn sé í gangi og svari staðbundið. Upptakan gerir það augljóst, og leiðatöflan útskýrir það.

Hafðu tvö undirnet í huga meðan þú lest restina. Annað er VPN-vistfangasafnið sem fjarskiptabiðlararnir koma frá, í þessu dæmi 10.64.0.0/24. Hitt er LAN sem verður að halda áfram að virka, 172.16.24.0/24 með beinisvæðinum sínum á 172.16.24.1. Villan er sú að umferð milli þeirra er ákveðin af sjálfgefnu leiðinni.

Sannaðu það með upptökunni og uppflettingunni

Áður en þú breytir einhverju skaltu staðfesta hvaða tæki svarið mun nota. Uppfletting er hraðari en upptaka og svarar nákvæmlega þeirri spurningu sem kjarninn mun svara þegar pakkinn er byggður.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lestu svarið í tveimur hlutum. Ef það nefnir dev tun0 mun hýsillinn pakka svarinu inn og afhenda veitandanum það, og LAN-biðlarinn mun aldrei sjá það. Ef það nefnir dev eth0 en biðlarinn fær samt tímaútrennsli er leiðin þegar rétt og pakkanum er hent síðar, sem er annað vandamál með aðra lagfæringu.

Upptakan í sama skrefi leysir þann efa sem ping getur ekki. Bergmálssvar sem berst til LAN-biðlarans sannar að einhver leið virki, ekki hvaða tengi bar það, svo keyrðu upptökuna á hýsilnum sjálfum og fylgstu með hvaðan rammarnir fara út. Prentari á sama undirneti heldur áfram að svara, því bein leið hans er nákvæmari en sjálfgefna leið gangsins. Flutt port bregst nákvæmlega eins og hvert annað flæði, því taflan velur tengið en tengingin ekki.

Settu upp þrengstu leiðina sem vinnur á ganginum

Lengd forskeytisins ræður, ekki mælikvarðinn, svo leið fyrir biðlarasafnið um LAN-beinisvæðinn vinnur á hvaða sjálfgefinni leið sem VPN-biðlarinn setur upp. Ekki þarf mælikvarðaaðgerð, og sjálfgefna leiðin má vera nákvæmlega þar sem biðlarinn setti hana.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Notaðu replace í stað add, því biðlari sem tengist aftur hefur þegar sett upp sína eigin færslu og önnur add bregst með villu um fyrirliggjandi leið sem les eins og heimildavandamál. Á Windows-hýsli er hliðstæðan route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, þar sem -p heldur færslunni milli endurræsinga, þar sem biðlarinn getur byggt töfluna upp á ný þegar gangurinn kemur upp aftur. Á núverandi Windows-hýsli er studda hliðstæðan New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, en eldri route-skipunin er varðveitt sem eldri mynd.

Eitt atriði ræður því hvort þetta er rétt eða aðeins trúverðugt: næsta hopp verður að vera beinisvæðinn sem á raunverulega leiðina til baka til biðlaranna. Að beina leiðinni að vistfangi sem er sjálft náð í gegnum ganginn býr til lykkju sem birtist sem slitrótt tap frekar en hrein bilun. Staðfestu að næsta hopp sé á LAN-undirnetinu áður en þú staðfestir línuna.

Haltu svarinu eftir endurtengingu

Leið sem bætt er við í höndunum lifir í besta falli til næstu endurtengingar. Ef biðlarasafnið er kvikt skaltu festa það í stillingum þjónsins svo forskeytið sem þú leiddir haldist það forskeyti sem biðlararnir fá; annars bendir færslan á tómt bil og einkennin koma aftur vikum síðar án augljósrar orsakar. Að skrifa leiðina í eigið up-skript biðlarans er hinn áreiðanlegi valkostur, því það keyrir eftir að biðlarinn hefur endurskrifað töfluna.

Stöðutengdur eldveggur getur samt sigrað rétta leið. Ef upptakan sýnir nú að svarið fer út um eth0 og biðlarinn fær samt tímaútrennsli skaltu athuga hvort hýsillinn hendir pakkanum áður en hann er sendur. Ströng síun á öfugri leið og net.ipv4.conf.all.rp_filter stillt á 1 henda pökkum sem uppruni þeirra yrði ekki leiddur til baka út um tengið sem þeir komu inn á, og það er nákvæmlega ósamhverfa tilvikið sem þú varst að búa til og lagaðir síðan, og conntrack-ástand segir sömu sögu fyrir flutt port.

Síðasta prófunin er sú sem fólk sleppir: endurtaktu uppflettinguna eftir að gangurinn hefur verið niðri og komið upp aftur. Fjögur gildi eiga að passa við það sem þú skrifaðir niður: áfangastaðurinn, næsta hopp, tækið og valinn uppruni. Ef eitthvað þeirra færðist hefur biðlarinn endurskrifað töfluna og lagfæringin á heima í krókum hans en ekki í shell-sögu.