VPN-biðlar ná netþjóninum en ekki LANinu: hvaða lausn?

Biðillinn pingar göngufangið hjá OpenVPN-netþjóninum og fær svar, prófar síðan hýsil á LANi netþjónsins og fær ekkert. Sú skipting þrengir bilanatölu verulega: göngin eru uppi, framsending virkar líklega, og svarið fer út um hurð sem leiðir ekki til baka. Þrjár lausnir eru til, og sú rétta fer eftir því sem þú stýrir og því sem þú ert reiðubúinn að gefa eftir. Svaraðu þremur spurningunum hér að neðan í röð og valið er ekki lengur smekksatriði.

Staðfestu fyrst hvor áttin er biluð

Beiðnin kemur inn á gönguviðmótið með upprunafangi úr VPN-lauginni. Netþjóninn sendir hana áfram til LAN-hýsilsins, og sá hýsill svarar þeirri gátt sem hans eigin tafla nefnir, venjulega LAN-beininum. Ef beinirinn hefur enga leið fyrir laugina deyr svarið þar eða reikar í átt að internetinu.

Prófaðu báðar vélarnar áður en þú breytir annarri. Spurðu beinatófluna á netþjóninum hvernig hún myndi ná í biðil; spurðu LAN-hýsilinn hvernig hann myndi ná sama fangi. Fyrsta uppflettingin bendir venjulega á göngin og sú seinni á LAN-beininn, og sá munur er bilanin í einni línu. Tvær uppflettingar eru ódýrari en eldveggjaskoðun og þær ákvarða átt vandans.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ef LAN-hýsillinn bendir þegar á VPN-netþjóninn er vandamálið þitt eldveggjarregla eða MTU-mörk en ekki vantar afturleið. Bættu ekki við leið til að laga síu.

Fyrsta spurning: getur þú breytt beininum á fjarlæga LANinu?

Þegar LAN-beinirinn er þinn er kyrr leið fyrir VPN-laugina með LAN-fangi VPN-netþjónsins sem næsta stökk hreint svar. Hún heldur upprunaföngum biðlanna óbreyttum, sem skiptir máli þegar LAN-hýslar skrá, sía eða takmarka hraða eftir fangi. Hún þarf heldur enga þýðingu á netþjóninum, svo göngin haldast hrein beinleið. Skyldan sem hún skapar er skjölun, því laugin, leiðin og stilling netþjónsins verða að stemma.

Hún bregst hljóðlaust daginn sem einhver breytir lauginni. Skrifaðu gildið niður einu sinni og líttu á breytingu á einum af þremur stöðum sem breytingu á öllum.

NAS eða lag-3 rofi sem hýsir þjónustuna þarf sömu leið nema hann sendi allt um beini sem hefur hana. Athugaðu tækið sem endar undirnetið, ekki bara það sem snýr að internetinu. Lítil net hafa oft þrjú tæki með skoðun á beinun.

Önnur spurning: má LANið hætta að sjá föng biðla?

Þegar beinirinn tilheyrir öðrum þarf þýðing á VPN-netþjóninum enga samvinnu. LAN-hýsillinn sér LAN-fang netþjónsins, svarar því, og netþjóninn þýðir til baka. Þess vegna haga tæki og NAT-byggð fjaraðgangshlutverk sér þannig.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Kostnaðurinn er rekjanleiki: föng á hvern biðil hverfa úr LAN-skrám. Sérhver heimiluð listi á LAN-hýslinum verður þá að nefna netþjóninn í stað laugarinnar.

Veldu þýðingu þegar samvinna er ekki í boði, ekki þegar hún er bara óþægileg. Hún felur biðilinn fyrir hverri framtíðarrannsókn, líka þeim þar sem þú þarft að vita hvaða fartölva opnaði tengingu. Hún getur líka brotið samskiptareglur sem fella föng inn í farminn, því þýðingin býr í hausnum. Hvorugur kosturinn er fullkomnari; þeir svara mismunandi spurningum um eignarhald.

Þriðja spurning: er netþjóninn sjálfur biðill að öðrum göngum?

Hugsaðu þér hina skipanina: VPN-netþjóninn hringir líka í verslunarveitu, svo hann hefur tvö göng og tvö fangasöfn. Umferð sem hann sendir áfram fyrir eigin biðla fer út um veituna, og hún beinir svörum ekki til baka á laugarföng. Þess vegna hverfa svörin þótt bæði göngin séu heilbrigð.

Lausnin er að dulbúa líka útleiðargöngin, svo veitan sjái aðeins göngufang netþjónsins. Andstæða áttin þarf sína eigin reglu, því netþjóninn sem hefjar tengingu við einn af sínum eigin biðlum er annað flæði. Án þeirrar reglu svarar biðillinn fangi sem hann getur ekki beint. Settu þröngu regluna fyrir hverja víða dulbúningu svo sérstaka þýðingin vinni.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Fjölheimtaugahýslar bæta við skyldri bilun sem lítur eins út frá biðlinum. Svarið fer út um viðmótið með lægra mæligildið því upprunafangið var valið úr annarri töflu. Athugaðu afturleiðina með uppflettingu í stað þess að ganga út frá því að framleiðin gefi hana.

Staðfestu síðan báðar áttir og báðar stærðir

Eftir breytinguna, pingaðu frá biðlinum til LAN-hýsils og síðan frá LAN-hýsilnum til biðilsins. Seinni áttin er sú sem fólk sleppir, og hún er sú sem palstrar ófullkomna þýðingarreglu. Skráðu bæði úrslit með tímasetningum svo síðari afturför sé samanburðarhæf.

Færðu síðan raunveruleg gögn, því lítið ping sem gengur á meðan stór flutningur stöðvast er MTU-einkenni. Sú bilun birtist rétt eftir að þú hefur óskað þér til hamingju með að laga leiðina.

Prófaðu að lokum aftur eftir endurræsingu. Keyrsluleiðir og eldveggjaskipanir lifa hana ekki af, og lausn sem hverfur við næstu ræsingu verður greind aftur af einhverjum með minni samhengi. Gerðu breytinguna varanlega á þann hátt sem kerfið þitt gerir nú þegar, og endurræstu svo einu sinni viljandi.