LAN-beinir og VPN-viðskiptavinur: tvö tæki, tvær leiðatöflur

Tvö tæki senda pakkann áfram og hvort heldur sína töflu. LAN-beinirinn veit að fjarlæga forskeytið tilheyrir VPN-viðskiptavininum, og VPN-viðskiptavinurinn veit hvernig á að ná því forskeyti gegnum gönguna sína. Stilltu aðeins fyrstu töfluna og pakkinn kemur að vél sem hefur enga samsvarandi leið, svo hann fer aftur út um sjálfgefnu leiðina. Það er öll bilunin, og frá LAN-hlið lítur hún út eins og leiðarlykkja, því hún er næstum það.

Teiknaðu hoppin tvö áður en þú snertir leið

Taktu skýringarmynd: LAN-vélar á 192.168.50.0/24, venjulegi beinirinn á 192.168.50.1, sérstakur viðskiptavinur á 192.168.50.15 og fjarlægt LAN á 10.60.0.0/24 sem aðeins er hægt að ná gegnum gönguna sem sá viðskiptavinur heldur. Hvort tveggja einkasviðanna skarast ekki við hitt, og göngin hafa sína eigin vistfangaskipan.

Bæði einkasviðin skipta máli því þau ráða því hvaða tæki getur svarað. Fjarlæga hliðin sér pakkann koma frá gönguvistfangi viðskiptavinarins, og svar hennar verður að finna leið aftur til 192.168.50.0/24. Ef aðeins útleiðin er stillt getur beiðnin virkað á meðan svarið hverfur.

Skref 1: beindu beininum að viðskiptavininum, ekki að göngunum

Á LAN-beininum, bættu við áfangaleið þar sem næsta hopp er LAN-vistfang viðskiptavinarins:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Sú færsla segir „skilaðu því til vélarinnar sem getur túnelerað“. Hún segir ekkert um hvernig göngin eru byggð, og hún kemur ekki í stað eigin leiðar viðskiptavinarins. Á stýrðum beini býr hliðstæðan á síðu tækisins fyrir kyrrstæðar leiðir; á Linux-beini tilheyrir hún stillingum viðmótsins sem á LAN-ið, ekki skel sem þú lokar.

Athugaðu svar seinni skipunarinnar. Ef hún tilkynnir viðskiptavininn sem gateway og LAN-viðmótið sem device, er fyrsta hoppið rétt og afgangur vinnunnar er á hinni vélinni.

Skref 2: gefðu viðskiptavininum eigin leið á gönguhliðinni

Viðskiptavinurinn fær nú pakka fyrir 10.60.0.0/24 og flettir upp í eigin töflu. Ef göngustillingin hans setti upp leið fyrir það forskeyti heldur pakkinn áfram dulkóðaður. Ef ekki, passar pakkinn við venjulegu sjálfgefnu leiðina og fer aftur til 192.168.50.1, sem sendir hann aftur til viðskiptavinarins.

Líttu áður en þú bætir einhverju við:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Vantar forskeytisleið í öllum töflum er sú niðurstaða sem þú ert að leita að. Bættu henni við í gegnum eigin stillingar göngunnar, svo næsta endurtenging setji hana upp aftur; handvirk ip route add hverfur með setunni og lætur bilunina koma aftur á óhentugasta tíma. Næsta hopp er gönguviðmótið eða vistfangið sem VPN-ið úthlutar sem jafningja sínum, eftir viðskiptavininum, og jafningjavistfangið ætti að koma úr núverandi sniði en ekki gömlum minnispunkti.

Lykkjan er, þegar hún verður, ekki óendanleg í reynd: TTL lækkar á hverri ferð og pakkinn deyr með skilaboðum um tíma sem er liðinn. Þess vegna getur endurtekið traceroute gefið til kynna hringrás á meðan viðskiptavinur sem einfaldlega sendir ekki áfram sleppir sama pakka hljóðlega.

Skref 3: leyfðu sendingu áfram og veldu pöntunarleiðina

Að taka við og að senda áfram eru mismunandi heimildir. net.ipv4.ip_forward=1 á viðskiptavininum leyfir gegnumferð á kjarnastigi, og eldveggjarregla verður samt að leyfa hana milli LAN-viðmótsins og gangnanna. Regla sem leyfir aðgang að eigin stjórnunarsíðu viðskiptavinarins leyfir ekki gegnumferð til fjarlæga LAN-sins, og auðvelt er að missa sjónar á muninum þegar sama vélin svarar pingum á staðnum.

Fjarlæga hliðin hefur spegilvandamálið. Hún verður að vita að 192.168.50.0/24 er aðgengilegt gegnum þennan auðkennda viðskiptavin. Með OpenVPN þýðir það venjulega leið fyrir hvern viðskiptavin sem stilling netþjónsins ýtir út, eða viðskiptavinasértæka skrá á netþjóninum sem lýsir LAN-inu bak við viðskiptavininn. Án þess sleppir fjarlæga LAN-ið svarinu eða sendir það á sína eigin sjálfgefnu gátt, sem er internetið.

Upprunaaðlögun er valkosturinn þegar ekki er hægt að auglýsa LAN-forskeytið. Takmörkuð masquerade-regla á viðskiptavininum endurskrifar upprunann í gönguvistfangið, og svör fara þá eðlilega til baka. Hún felur líka hvaða LAN-vél lagði fram beiðnina, og leyfir ekki af sjálfu sér fjarlægu hliðinni að hefja tengingar inn á við. Veldu þennan skiptikost viljandi í stað þess að bæta við almennri masquerade og uppgötva aukaverkunina seinna.

Skref 4: gerðu báðar ákvarðanir varanlegar og prófaðu svo raunverulegu leiðina

Hver leið hefur eiganda, og eigandinn er stillingin sem er endurnýjuð við ræsingu eða endurtengingu. Á beininum getur það verið færsla kyrrstæðrar leiðar; á viðskiptavininum getur það verið VPN-sniðið, NetworkManager eða systemd-networkd. Sannprófaðu með því að endurtengja göngin og endurræsa viðskiptavininn, og lestu svo töfluna aftur í stað þess að treysta breytingunni.

Haltu sjálfgefnu leiðinni sem flytur ytri tengingu gangnanna ósnortinni. Að skipta henni út til að „einfalda“ uppsetninguna brýtur dulkóðuðu leiðina áður en nokkur innri umferð getur notað hana, og einkennið er göng sem koma aldrei aftur upp eftir breytinguna.

Prófaðu frá venjulegri LAN-vél, ekki frá viðskiptavininum, því beiðni sem verður til á viðskiptavininum nýtir aldrei fyrsta hopp beinisins. Sæktu þjónustu sem er aðeins til á fjarlæga LAN-inu og staðfestu svarhlutann, og skoðaðu svo teljara eða annála viðskiptavinarins til að sjá gegnumferðina. Innra traceroute sem sýnir einkahoppingar sannar sendingu áfram, ekki dulkóðun: ytri leiðin er sérstök athugun, og aðeins teljarar gönguviðmótsins sjálfs sýna hvað fór út um það.