Hvers vegna Access Server-biðlarar eru óaðgengilegir frá LAN-inu
Beintir biðlarar halda laugarheimilisfangi sínu, svo svörin þurfa leið til baka. Lestu upprunann hjá þjónustunni og bættu síðan laugaleiðinni við á rétta gátt.
Fartölvan tengist, göngin eru uppi og beiðnir til innri þjónustu hanga við tengingu. Hjá þjónustunni sjálfri kemur beiðnin frá heimilisfangi eins og 10.90.0.25, svarið fer út í átt að sjálfgefnu gáttinni og ekkert kemur til baka, því sú gátt hefur ekki hugmynd um hvar 10.90.0.25 býr. Frá hinum endanum lítur sama bilun út eins og innri hýsill sem getur ekki pingað tengdan biðil. Bæði eru eitt fyrirbæri sem vantar: leið til baka að VPN-biðlalauginni, sem aðeins einkanetið getur bætt við.
Lestu upprunafangið sem þjónustan sér
Það eina svið ræður öllu hinu. Ef innri þjónustan sér laugarheimilisfangið er Access Server að beina umferð biðla í stað þess að fela hana, og hvert svar verður að beina aftur í laugina. Ef hún sér hins vegar eigið einkanet heimilisfang þjónsins er þjónninn að nota masquerade og leiðin til baka virkar þegar, en á þann kostnað að auðkenni hvers biðils tapast í atburðaskrá og aðgangsreglum þjónustunnar.
Berðu saman báða enda áður en þú breytir einhverju. Á þjóninum skaltu lista gönguviðmótin og heimilisföng þeirra; á biðlinum skaltu staðfesta hverjir þessara heimilisfanga hann hefur í raun; á innri hýslinum skaltu skoða virka tengingu.
ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25Síðasta skipunin er sú sem mistekst í biluðu tilfellinu: hún tilkynnir annaðhvort að forskeyti gagnanna sé óaðgengilegt eða, verra, skilar sjálfgefnu gáttinni þinni, og þannig enda svörin á internetinu.
Ekki gera ráð fyrir aðeins einni laug. Þjónn getur haft kraftmikið svið auk kyrrstæðra varpana á hvern notanda, og kyrrstæða heimilisfangið getur verið alveg utan við kraftmikla forskeytið. Ef þú beinir aðeins sviðinu sem þú manst eftir, verða notendur með föst heimilisföng áfram í ólagi og allir aðrir tilkynna að vandamálið sé leyst.
Bættu leiðinni við þar sem svarið er ákveðið
Leiðin tilheyrir gáttinni sem innri þjónustan notar þegar, ekki þjónustunni, nema hún beini eigin umferð. Beindu henni að aðgengilegu einkanet heimilisfangi Access Server, sem er annað gildi en gagnsheimilisfangið sem biðill hefur.
ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25Í skýjaneti verður sama fullyrðing færsla í leiðatöflu þar sem markmiðið er eintakið eða netviðmótið sem þjónninn keyrir á, með uppruna- og áfangastöðvun slökkt á því viðmóti. Taktu eftir því sem sú færsla gerir ekki: leið er ekki aðgangsheimild, svo öryggishópar, net-ACL og eldveggur hýsilsins verða enn að leyfa umferðina.
Gerðu hana varanlega og haltu laugarstærðunum heiðarlegum. Tvær ósamhangandi laugar þurfa tvær leiðir, og laug sem vex út fyrir uppsett forskeyti sitt framleiðir hljóðlaust biðla sem svörin eiga hvergi leið. Ef þú stjórnar laugasviðunum skaltu velja samantekt sem þú getur beint einu sinni og látið vera.
Framsending og síur verða að passa við leiðina
Beining er aðeins helmingur leiðarinnar. Þjóninum verður að vera heimilt að framsenda milli gagnanna og einkaviðmótsins, sem á Linux þýðir net.ipv4.ip_forward auk framsendingarkeðju sem leyfir viðmótaparið, og á harðgerðum hýsli venjulega skýra reglu fyrir hvora stefnu.
sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forwardÁstandsstýrð síun skýrir einkenni sem sendir fólk á ranga leið. Svar innan þegar myndaðs flæðis þarf ekki nýja reglu fyrir inngöngu, svo tenging sem hangir eftir SYN-ACK er ekki stífluð af reglu sem vantar; henni er sleppt eða henni er beint vitlaust. Haltu þessum mun, því hann aðgreinir breytingu á beiningu frá breytingu á eldvegg.
Ósamhverfar leiðir til baka eru hljóðlátari útgáfan af sama vandamáli. Ef tvær leiðir ná til laugarinnar og svarið fer þá leið sem liggur út um annað viðmót en beiðnin kom inn um, þá sleppir ströng bakleiðarsíun henni og flæðið mistekst aðeins fyrir suma biðla.
Beint eða masquerade: veldu af ásetningi
Beint hamur varðveitir laugarheimilisfang biðilsins hjá þjónustunni, sem gerir atburðaskráningu og stefnu á hvern biðil mögulega, og í staðinn þarf hvert innra net sem á að svara biðil laugaleiðina. Masquerade-hamurinn fjarlægir þá kröfu því svörin fara aftur til þjónsins, en þjónustan getur ekki lengur greint einn biðil frá öðrum og getur ekki hafið neitt í átt að tilteknum biðil.
Að breyta þessari hegðun á lifandi þjóni slekkur á núverandi setum, svo prófaðu fyrst með einum biðil og einu flæði. Ef skiptingin er rétta svarið er það stillingarákvörðun á þjóninum, ekki eitthvað sem sniðgengið er með því að bæta við leiðum sem verða óþarfar.
Undirnet bak við biðilinn er sérstakt verkefni
Að ná í tæki á eigin LAN fartölvunnar er ekki það sama og að ná í gagnsheimilisfang fartölvunnar. Það krefst þess að biðillinn starfi sem gátt undirnets: tilkynnt net á biðlahlið, framsending virkjuð í stýrikerfi biðilsins og leið á því LANi aftur í átt að biðlinum. Að bæta við einkanetsleið fyrir heimasvið fartölvunnar gerir þetta ekki, og það skapar árekstra þegar tveir notendur hafa sama heimasvið.
Stefnan er líka stefnumál. Heimild fyrir biðil að opna tengingu við innri þjónustu leyfir ekki sjálfkrafa innri hýsli að opna tengingu við þann biðil. Athugaðu aðgangsstefnu þjónsins og eldvegg hýsilsins áður en þú ályktar að leiðin sé biluð.
Staðfestu með einu flæði og einni skráningu
Sannaðu leiðina með einni tengingu í stað almenns aðgengisprofs. Fylgstu með sama flæði á báðum endum: beiðninni sem kemur til þjónustunnar og svarinu sem yfirgefur hana.
tcpdump -ni any host 10.90.0.25 and port 443Fyrir lagfæringu sýnir skráningin svarið fara í átt að gátt sem mun ekki beina því. Eftir lagfæringu fer svarið í átt að þjóninum og flæðið klárast. Staðfestu síðan leiðina sem gáttin myndi nota fyrir annað biðlafang, svo laug sem þú hefur ekki náð yfir birtist núna en ekki eftir viku.
Lokaðu með fjórum athugunum sem girða málið: upprunafangið hjá þjónustunni passar við haminn sem þú ætlaðir, gáttin hefur leið að hverri laug í notkun, framsending og síur leyfa báðar stefnur, og eitt raunverulegt flæði klárast frá enda til enda. Algengar spurningar um beiningu Access Server setur fram sömu meginreglu fyrir uppsettu útgáfuna, en studd stilliviðmót hennar geta verið frábrugðin eldri leiðbeiningum.