VPN ja kotiverkko samassa aliverkossa: käy reitti läpi ensin
Molemmat sovittimet vaativat 192.168.1.0/24:n ja yksi reitti voittaa. Käy läpi sovitinluettelo, voittava reitti ja paluureitti ennen kuin numeroit uudelleen tai syytät DNS:ää.
Yhdistät toimiston VPN:ään, ilmaisinalueen kuvake muuttuu vihreäksi, intranet latautuu ja kahden metrin päässä oleva tulostin lakkaa vastaamasta. Jaettu kansio, joka toimi aamulla, aikakatkaistaan samalla koneella, eikä mikään loki mainitse tulostinta. Refleksi on DNS, koska nimi, joka ei ratkea, näyttää nimeltä, jota ei ole olemassa, mutta ongelma on osoitteessa: kaksi sovitinta vaatii nyt 192.168.1.0/24:n ja vain yksi reitti voi voittaa sen etuliitteen. Käy se läpi tässä järjestyksessä, niin näet, mikä sovitin otti sen, ennen kuin muutat mitään.
Aloita oireesta, älä tunnelista
Vihje on laajuus. Jos intranet toimii ja jokainen paikallinen laite epäonnistuu, tunneli on kunnossa ja paikallinen polku ei. Jos paikalliset laitteet toimivat ja intranet epäonnistuu, toisin päin. Jos kaikki muu toimii paitsi yksi isäntä, edessäsi on yksi osoite, joka on olemassa molemmilla puolilla.
Kirjoita yksi paikallinen ja yksi etäinen osoite muistiin ennen kuin kosket asetukseen. “Tulostin” ei ole testattavissa; 192.168.1.40 on. Se yksi askel estää tämän ongelman yleisimmän hukatun tunnin, eli DNS-asetusten uudelleenkirjoittamisen reitityspäätöksen takia.
Vaihe 1: näe molemmat sovittimet vaatimassa etuliitettä
Avaa Verkkoyhteydet (ncpa.cpl) ja lue kaksi sovitinta rinnakkain. Ethernet-sovitin näyttää 192.168.1.50/24 yhdyskäytävällä 192.168.1.1. VPN-sovitin näyttää 192.168.1.201/24, jonka palvelin työnsi. Molemmat ovat laillisia, molemmat uskovat etuliitteen olevan on-link, ja pino pitää sille yhden reitin.
Get-NetIPAddress -AddressFamily IPv4 luettelee osoitteet ja Get-NetIPInterface | Sort-Object InterfaceMetric näyttää järjestyksen, jossa pino käyttää niitä. Se metriikkasarake on päätös, jonka aiot lukea, joten kirjoita numerot muistiin sen sijaan että yrittäisit muistaa ne.
Todista DNS-teoria halvalla vääräksi: Resolve-DnsName printer.office.lan palauttaa saman osoitteen kuin eilen. Nimi ratkesi; paketti lähti sitten väärästä sovittimesta. Kaksi minuuttia tässä säästää iltapäivän resolverin asetuksissa.
Vaihe 2: lue reitti, joka todella voitti
Find-NetRoute -RemoteIPAddress 192.168.1.40 tulostaa liittymän, seuraavan hypyn ja lähteen, jota pino käyttäisi kyseiselle osoitteelle. Kohtele tätä tulosta vastauksena, älä vihjeenä. route print -4 antaa koko taulukon, kun haluat nähdä, mikä merkintä hävisi ja kuinka paljon.
Tarkkuus voittaa aikomuksen. Työnnetty 192.168.0.0/25 voittaa paikallisen 192.168.0.0/24:n, koska etuliite on pidempi, joten 192.168.0.0–192.168.0.127 lähtee tunnelin kautta, kun yläpuolisko jää paikalliseksi. Puolen verkon katoaminen ilman virheilmoitusta on tuon taulukon oikea käytös.
tracert -d 192.168.1.40 vahvistaa sen taulukon ulkopuolelta: jos ensimmäinen hyppy on tunnelin osoite eikä oma reitittimesi, reitti on koko tarina. Linuxissa sama kysymys on ip route get 192.168.1.40, joka tulostaa lähdeosoitteen ja laitteen yhdelle riville. Kun vastaus nimeää tun0:n, lopeta selaimen katsominen.
Vaihe 3: tarkista paluureitti ennen kuin syytät asiakasta
Oikea eteenpäin menevä reitti epäonnistuu silti, jos kaukopää ei voi vastata. Kun asiakkaan verkkoon päästään tunnelin kautta, sen verkon yhdyskäytävän on tiedettävä, missä tunneliallas sijaitsee: ip route add 10.8.0.0/24 via 192.168.1.12 kyseisellä reitittimellä, ja push “route 192.168.1.0 255.255.255.0” palvelimelta, jotta asiakkaat tuntevat paluureitin.
Ilman ensimmäistä merkintää vastaus lähtee kohteesta kohti sen oletusyhdyskäytävää, joka välittää yksityisen osoitteen operaattorille ja pudottaa sen. Oire on yksisuuntainen ja helposti väärin luettava: pyynnöt näkyvät tun0:lla, vastaukset eivät koskaan.
Masquerade-sääntö VPN-isännässä poistaa tarpeen tuolle staattiselle reitille: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Se myös piilottaa todelliset lähdeosoitteet, mikä vaikeuttaa jokaista myöhempää lokikysymystä. Kohdeisäntä, jolla on väärä oletusyhdyskäytävä, tuottaa saman hiljaisuuden, parhaimmillaan ICMP-uudelleenohjauksen ja normaalisti mustan aukon, ja siksi kaappaus kuuluu molempiin päihin.
Vaihe 4: valitse korjaus, jonka kanssa voit elää
Tähän käytetään viittä korjausta, eivätkä ne ole vaihdettavissa. Valitse sen mukaan, minkä on pysyttävä saavutettavana samanaikaisesti, ei sen mukaan, mikä komento on lyhin.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Metriikat ovat halpa vaihtoehto ja se, johon ihmiset tarttuvat ensin. Muutos koskee liittymää, joten se toimii, kun tunneli on pystyssä, ja se kuuluu asiakkaan viereen skriptiin, ei kuoreen, jonka unohdat. Se ei voi antaa samanaikaista pääsyä samaan osoitteeseen kahdessa verkossa, ja juuri se raja lähettää kaikki muut taulukon alaosaan.
Kotiverkon uudelleennumerointi 10.10.0.0/24:ään on puhdas ratkaisu: yksi DHCP-vuokrasuhteen uudistus sekä varaukset, tulostusjonot ja kovakoodatut osoitteet, jotka mainitsevat vanhan alueen. Toimiston puolen uudelleennumerointi ei yleensä ole sinun päätöksesi. IPv6 poistaa törmäyksen kokonaan, kun molemmat verkot kantavat sitä, käyttäen yksilöllistä paikallista etuliitettä fd00::/8:sta jonkin muistettavan sijaan, mutta testaa sovellus TCP:n yli, älä pingillä, koska ICMP voi toimia, vaikka palvelu ei.
OpenVPN:n oma käännösvaihtoehto on viimeinen keino, joka työnnetään palvelimelta asiakaskohtaiseen hakemistomerkintään. Se ottaa vaihtoehdon nimen jälkeen neljä parametria — suunta, verkko, peite ja alias — eikä alias ole valinnainen: push "route 192.168.2.0 255.255.255.0" ja push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Verkko ja peite ovat alue, jonka asiakas näkee (192.168.2.0/24), alias on todellinen toimistoalue palvelimen puolella (192.168.1.0/24), ja työnnetty reitti tekee tuon näkyvän alueen saavutettavaksi. Toimisto näkyy silloin asiakkaalle 192.168.2.x:n alla. Dokumentoi kartoitus profiiliin, muuten seuraava henkilö selvittää sitä reititysvikana.
Yhden palvelun julkaiseminen on käännöksen kapea versio eikä tarvitse OpenVPN:n vaihtoehtoa lainkaan. DNAT-sääntö VPN-isännässä julkaisee yhden portin uudelleen, joten verkko säilyttää osoitteensa ja saavuttaa palvelun isäntäosoitteessa, jonka se jo tuntee. Hinta on tavallinen: palvelu näkee VPN-isännän lähteenä, joten asiakaskohtaiset lokit ja käänteishaut menettävät merkityksensä. Se kattaa yhden tulostusjonon tai yhden ylläpitosivun, ei molemmilla puolilla olevia isäntiä, jotka saavuttavat toisensa.
Mikä ei silti tule toimimaan, ja mitä kirjata
Lähetys ei ylitä reititettyä tunnelia. DLNA, UPnP, NetBIOS-selaus ja Wake-on-LAN riippuvat lähetyksestä tai multicastista, jota tun-laite ei kanna, joten mikään reitti ei korjaa löytämistä. Sillaus dev tapilla laajentaa segmenttiä ja sen mukana DHCP-lähetykset, ARP:n ja kaikki muut löytämispaketit; suosi unicast-isäntäreittiä kuten route 192.168.2.1 255.255.255.255 kaukaisen reitittimen verkon puolen osoitteelle.
Kaksi reititintä, jotka molemmat käyttävät 192.168.1.1:tä samalla polulla, kuuluvat samaan ongelmaperheeseen: paikallinen osoite voittaa aina, joten kaukaisen reitittimen sivu pysyy tavoittamattomana, kunnes yksi verkko muuttaa. Toisen sovittimen lisääminen ei muuta kummassakaan tapauksessa mitään.
Kirjaa todisteet ennen kuin muokkaat mitään: ip route get tai Find-NetRoute, ping -c 3 kyseiseen osoitteeseen, traceroute ja tcpdump -ni tun0 icmp asiakkaalla, sitten reititystaulukko ja NAT-laskurit palvelimella. Ping, joka toimii yhteen suuntaan ja kuolee toiseen, osoittaa paluureittiin, ei tunneliin, ja juuri se ero ratkaisee, minkä yllä olevista korjauksista todella tarvitset.