Svar staðar-til-staðar VPN fer ekki í gegnum göngin

Ég eyddi morgni í göng sem komu upp hreinlega og fluttu umferð nákvæmlega í eina átt: útibúið náði í skráaþjóninn á höfuðstöðvunum, og hver tenging sem var opnuð frá höfuðstöðvunum inn í útibúið dó við fyrsta SYN. SA-arnir voru virkir, teljarar gagnanna hækkuðu, og handabandið var aldrei vandamálið. Svarinu var beint eitthvert þangað sem göngin ná ekki yfir, og það val tilheyrir hinum endanum. Staðar-til-staðar VPN flytur aðeins þau pakka sem hýsill afhendir gáttinni, og hver hýsill tekur þá ákvörðun sér, í hvora áttina sem er, út frá sinni eigin leiðartöflu.

Báðar áttir eru leiðarvaldar sér

IP geymir enga minningu um átt samræðna. Hver hýsill sem sendir pakka keyrir sína eigin leit að lengsta forskeytinu, velur eitt næsta hopp og gleymir ákvörðuninni. Beiðnin og svarið eru tveir ótengdir pakkar sem tilheyra fyrir tilviljun sömu tengingu, og göngin eru eitt hopp sem hvort þeirra getur notað eða ekki. Ekkert í IKE-skiptunum kennir fjartengdum þjóni hvernig á að ná í undirnetið þitt; samningaviðræðurnar samþykkja aðeins hvaða forskeyti megi dulkóða.

Sá samningur er annað hliðið. Hjá strongSwan eru umferðarvalarnir leftsubnet og rightsubnet, og pakki þar sem uppruni eða áfangastaður fellur utan samningsins er ekki dulkóðaður, hvað sem leiðartaflan segir. Forskeyti sem er leiðarvalið inn í göngin en vantar í valarana er hljóðlátt einátta bilun: leiðin virðist rétt, pakkinn fer samt út ódulkóðaður eða er hent, og aðeins charon-loggurinn kvartar.

Fjartengdi hýsillinn veit ekkert um göngin þín

Inni í fjartengdu LAN-inu er svarið venjulegur pakki sem er stílaður á biðlarann þinn. Áfangahýsillinn sér enga IPsec-haus og hefur enga ástæðu til að velja VPN-gáttina fram yfir; hann flettir upp forskeytinu þínu, finnur ekkert nánar skilgreint en sjálfgefna leiðina sína og fylgir henni. Ef sjálfgefna leiðin vísar á kjarnavarnarvirki, þá hefur það annaðhvort leið aftur inn í göngin eða ekki. Þegar ekki er, færðu hljóðláta hendingu, ICMP unreachable eða svar sem fer út um netviðmótið og deyr.

Annað netviðmót nægir til að brjóta þetta jafnvel þegar leið er til. NAS með stjórnendutengingu á öðru VLAN, þjónn með varauplink, stefnuregla sem sendir eitt upprunasvið í aðra töflu: hvað sem er af þessu getur gripið svarið. Á Linux sýna ip rule show og ip route show table all reglur og töflur sem sjálfgefni listinn leynir.

Lestu ákvörðunina á vélinni sem sendir svarið

Spyrðu kjarnann áður en þú breytir einhverju, og gefðu honum upprunavistfangið, því reglur sem ráðast af upprunanum breyta svarinu.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Úttakið nefnir útviðmótið og næsta hopp. Ef viðmótið er ekki það sem snýr að VPN-gáttinni hefur þú fundið gallann, og eftir er að velja hvar leiðin á heima. Ping frá gáttinni sannar litlu hér: það svarar með vistfangi sem fjartengdi hýsillinn getur staðsett, ekki vistfangi fartölvunnar þinnar.

Á Windows eru samsvaranirnar Find-NetRoute -RemoteIPAddress 10.10.5.10 fyrir ákvörðunina og Get-NetRoute fyrir töfluna. Leið sem er bætt við með New-NetRoute og ber hærra mæligildi en sjálfgefna leiðin tapar hljóðlátt, svo lestu mæligildisdálkinn, ekki færsluna. Staðfestu svo með pökkum: tcpdump -ni any "host 10.10.5.10 and tcp port 445" á fjartengdu LAN-viðmóti sýnir beiðnina, og sami sía á göngunum sýnir hvort svar kom til baka. Sýnileg beiðni án svars þýðir að svarinu var beint annað eða því hent; svar á röngu viðmóti gefur þér sekan áður en þú snertir leið.

Þegar gátt þjónsins er ekki endapunktur VPN

Margir staðir setja varnarvirki milli þjónanna og miðlarans. Það varnarvirki sendir svarið áfram, svo það þarf leið fyrir forskeyti biðlarans þíns að VPN-gáttinni og áframsendingarstefnu í báðar áttir. Tæki með ástand gera þetta verra: beiðnin fór í gegnum varnarvirkið frá LAN-hýsli sem það leyfði, svarið kemur nú úr annarri átt, og færslan í tengingarakningunni passar ekki lengur, svo pakkanum er hent sem ógildum frekar en hafnað. Þess vegna virðist stefnuloggurinn tómur á meðan umferðin hverfur.

Gáttin hefur sína eigin aðra síu. Öfug leiðasíun Linux hendir pökkum þar sem uppruninn er ekki aðgengilegur um það viðmót sem þeir komu á, og það er nákvæmlega lögun lögmætrar ósamhverfrar endurkomuleiðar. áframsendingarleiðbeiningar strongSwan krefjast net.ipv4.ip_forward og slakaðs net.ipv4.conf.all.rp_filter einmitt þess vegna. Strangt gildið 1 á hvorri gáttinni sem er brýtur rétta leið hljóðlátt, og nstat -az sýnir hendingarnar ef þú veist hvar á að horfa.

Leiðarvísleggðu eða þýddu, og staðfestu svo í báðar áttir

Viðgerðirnar tvær eru ekki jafngildar. Að bæta við leið heldur vistfangi biðlarans óskertu, svo reglur sem byggja á upprunanum, endurskoðunarlogg og forrit sem skrá hringjandann halda áfram að virka; verðið er að hvert hopp sem tekur ákvörðunina þarf leiðina, sem eru fleiri staðir til að hafa rangt. Grímuklæðning á fjartengdu gáttinni minnkar endurkomuleiðina í eitt hopp, því svarinu er nú stílað á gáttina sjálfa, og leynir hvaða biðlari gerði hvað.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Veldu hana af ásettu ráði: um leið og biðlarar birtast sem vistfang gáttarinnar hætta upprunatengd ACL að greina þá að, og conntrack verður að halda varpinu svo svarið sé skrifað aftur inn í göngin. Ef valarnir útiloka enn forskeyti biðlarans breytir NAT engu, því beiðnin komst aldrei inn í göngin.

Áður en þú lýsir þessu læknu skaltu staðfesta fjóra hluti í röð: leiðina á hýslinum sem sendir svarið, leiðina á hverju hoppi sem sendir hana áfram, valarana sem ná yfir bæði forskeytin, og upptöku sem sýnir svarið fara inn í göngin með þeim uppruna sem þú býst við. Endurtaktu svo prófið frá hinum staðnum. Ein átt sem fer í gegn er hálfopnuð hönnun, og önnur áttin bregst yfirleitt af annarri ástæðu en þeirri sem þú varst að laga.