VPN og heimanet á sama neti: farðu fyrst eftir leiðinni

Þú tengist skrifstofu-VPN, táknið á bakkanum verður grænt, intranetið hleðst og prentarinn tveimur metrum frá hættir að svara. Deilimappan sem virkaði í morgun rennur út á sömu vél, og engin skrá minnist prentara. Viðbragðið er DNS, því nafn sem leysist ekki út lítur út eins og nafn sem er ekki til, en vandamálið er í vistfanginu: tveir millistykki gera nú tilkall til 192.168.1.0/24 og aðeins ein leið getur unnið það forskeyti. Farðu eftir þessu í þessari röð og þú munt sjá hvaða millistykki tók hana áður en þú breytir nokkru.

Byrjaðu á einkenninu, ekki göngunum

Vísbendingin er umfangið. Ef intranetið virkar og hvert staðbundið tæki bregst, er göngin heilbrigð og staðbundna leiðin ekki. Ef staðbundin tæki virka og intranetið bregst, þá öfugt. Ef allt virkar nema einn hýsil, ertu að horfa á eitt vistfang sem er til á báðum hliðum.

Skrifaðu niður eitt staðbundið og eitt fjarlægt vistfang áður en þú snertir stillingu. „Prentarinn“ er ekki prófanlegur; 192.168.1.40 er það. Þetta eina skref kemur í veg fyrir algengustu sóun klukkustundar í þessu vandamáli, sem er að endurskrifa DNS-stillingar vegna ákvörðunar um leiðarval.

Skref 1: sjáðu bæði millistykkin gera tilkall til forskeytisins

Opnaðu Netvenjur (ncpa.cpl) og lestu millistykkin tvö hlið við hlið. Ethernet-millistykkið sýnir 192.168.1.50/24 með gátt 192.168.1.1. VPN-millistykkið sýnir 192.168.1.201/24, ýtt frá þjóninum. Bæði eru lögmæt, bæði trúa því að forskeytið sé on-link, og staflinn heldur einni leið fyrir það.

Get-NetIPAddress -AddressFamily IPv4 telur upp vistfangin, og Get-NetIPInterface | Sort-Object InterfaceMetric sýnir röðina sem staflinn notar þau í. Sá mælikvarðadálkur er ákvörðunin sem þú ert að fara að lesa, svo skrifaðu tölurnar niður í stað þess að reyna að muna þær.

Afhjúpaðu DNS-kenninguna ódýrt: Resolve-DnsName printer.office.lan skilar sama vistfangi og í gær. Nafnið leystist; pakkinn fór svo út um rangt millistykki. Tvær mínútur hér spara síðdegi í stillingum leysandans.

Skref 2: lestu leiðina sem raunverulega vann

Find-NetRoute -RemoteIPAddress 192.168.1.40 prentar viðmótið, næstu hopp og uppruna sem staflinn myndi nota fyrir það vistfang. Líttu á þessa úttak sem svarið, ekki vísbendingu. route print -4 gefur allan töfluna þegar þú vilt sjá hvaða færsla tapaði og hversu mikið.

Sérhæfni vinnur hugvit. Ýtt 192.168.0.0/25 sigrar staðbundið 192.168.0.0/24 því forskeytið er lengra, svo 192.168.0.0 til 192.168.0.127 fara út um göngin á meðan efri helmingurinn verður staðbundinn. Að hálft net hverfi án villuboða er rétt hegðun fyrir þá töflu.

tracert -d 192.168.1.40 staðfestir það utan töflunnar: ef fyrsta hoppið er vistfang ganga í stað eigin beinis, þá er leiðin öll sagan. Á Linux er sama spurningin ip route get 192.168.1.40, sem prentar upprunavistfang og tæki á einni línu. Þegar svarið nefnir tun0, hættu að horfa á vafrann.

Skref 3: athugaðu bakleiðina áður en þú kennir viðskiptavininum um

Rétt leið áfram bregst samt ef fjarlæga hliðin getur ekki svarað. Þegar komist er í net viðskiptavinar um göngin verður gátt þess nets að vita hvar laug ganganna er: ip route add 10.8.0.0/24 via 192.168.1.12 á þeim beini, og push „route 192.168.1.0 255.255.255.0“ frá þjóninum svo viðskiptavinir þekki bakleiðina.

Án fyrstu færslunnar yfirgefur svarið markið í átt að sjálfgefinni gátt sinni, sem sendir einkavistfang til þjónustuaðilans og hendir því. Einkennið er einstefnu og auðvelt að lesa rangt: beiðnir birtast á tun0, svör aldrei.

Masquerade-regla á VPN-hýsilnum fjarlægir þörfina fyrir þá kyrru leið: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Hún hylur líka raunveruleg upprunavistföng, sem gerir hverja síðari skráaspurningu erfiðari. Markhýsill með ranga sjálfgefna gátt framleiðir sömu þögn, með ICMP-endurbeiningu í besta falli og svartan göt í hið venjulega, og þess vegna á upptakan heima á báðum endum.

Skref 4: veldu viðgerð sem þú getur lifað með

Fimm viðgerðir eru notaðar við þessu, og þær eru ekki skiptanlegar. Veldu eftir því hvað verður að vera aðgengilegt á sama tíma, ekki eftir því hvaða skipun er styst.

Mælikvarðar eru ódýri kosturinn og sá sem fólk grípur fyrst til. Breytingin gildir um viðmótið, svo hún virkar á meðan göngin eru uppi, og hún á heima í skriftu við hlið viðskiptavinarins frekar en í skel sem þú gleymir. Hún getur ekki veitt samtímis aðgang að sama vistfangi á tveimur netum, og það er takmörkunin sem sendir alla hina niður töfluna.

Endurnúmerun heimanetsins í 10.10.0.0/24 er hreina lausnin: ein DHCP-leiguendurnýjun auk frátekinna tákna, prentararaðar og harðkóðuðu vistfanganna sem nefna gamla bilið. Endurnúmerun skrifstofuhliðarinnar er venjulega ekki þín ákvörðun. IPv6 eyðir árekstrinum alveg þegar bæði netin bera það, með einstöku staðbundnu forskeyti úr fd00::/8 í stað einhvers auðmunaðs, en prófaðu forritið um TCP, ekki með ping, því ICMP getur virkað á meðan þjónustan gerir það ekki.

Eigin þýðingarvalkostur OpenVPN er síðasta úrræðið, ýtt frá þjóninum inn í skráarfærslu sem er sérstök fyrir viðskiptavininn. Hann tekur fjóra færibreytur eftir nafni valkostsins — stefnu, net, netgrímu og samheiti — og samheitið er ekki valfrjálst: push "route 192.168.2.0 255.255.255.0" og push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Netið og gríman eru bilið sem viðskiptavinurinn sér (192.168.2.0/24), samheitið er raunverulegt skrifstofubil á þjónshliðinni (192.168.1.0/24), og ýtta leiðin er það sem gerir það sýnilega bil aðgengilegt. Skrifstofan birtist þá þeim viðskiptavini undir 192.168.2.x. Skjalfestu vörpunina í sniðinu, annars mun næsta manneskja kemba hana sem leiðarvillu.

Að birta eina þjónustu er þrönga útgáfan af þýðingu, og hún þarf alls ekki valkost OpenVPN. DNAT-regla á VPN-hýsilnum birtir eina gátt aftur, svo netið heldur vistföngum sínum og nær þjónustunni á hýsilvistfanginu sem það þekkir nú þegar. Kostnaðurinn er venjulegur: þjónustan sér VPN-hýsilinn sem uppruna, svo skrár eftir viðskiptavinum og öfug uppfletting missa merkingu. Það nær yfir eina prentararöð eða eina stjórnunarsíðu, ekki hýsla á báðum hliðum sem ná hvort í annað.

Hvað mun samt ekki virka, og hvað á að skrá

Útsending fer ekki yfir beina göng. DLNA, UPnP, NetBIOS-vafur og Wake-on-LAN byggjast á útsendingu eða margsendingu sem tun-tæki ber ekki, svo engin leið lagar uppgötvun. Brúun með dev tap lengir sneiðina, og með henni DHCP-útsendingar, ARP og hvern annan uppgötvunarpakka; veldu frekar einstefnu hýsilleið eins og route 192.168.2.1 255.255.255.255 fyrir netshliðar-vistfang fjarlægs beinis.

Tveir beinar sem báðir nota 192.168.1.1 á sömu leið tilheyra sömu vandamálaætt: staðbundna vistfangið vinnur alltaf, svo síða fjarlæga beinisins er óaðgengileg þar til eitt net flyst. Að bæta við öðru millistykki breytir engu í hvorugu tilvikinu.

Skráðu sönnunargögnin áður en þú breytir nokkru: ip route get eða Find-NetRoute, ping -c 3 á viðkomandi vistfang, traceroute, og tcpdump -ni tun0 icmp á viðskiptavininum, síðan leiðartöfluna og NAT-teljarana á þjóninum. Ping sem virkar aðra leiðina og deyr hina bendir á bakleiðina, ekki göngin, og sá eini greinarmunur ræður því hverra viðgerðanna hér að ofan þú þarft í raun.