VPN kaj hejma LAN sur la sama subreto: unue sekvu la itineron
Ambaŭ adaptiloj postulas 192.168.1.0/24 kaj unu itinero gajnas. Sekvu la adaptilan liston, la gajnan itineron kaj la revenan vojon antaŭ ol renumerigi aŭ kulpigi DNS.
Vi konektiĝas al la ofica VPN, la ikono en la sistemopleto verdiĝas, la intraneto ŝargiĝas, kaj la printilo du metrojn for ĉesas respondi. La kunhava dosierujo, kiu funkciis matene, tempolimas sur la sama maŝino, kaj neniu protokolo mencias printilon. La reflekso estas DNS, ĉar nomo, kiu ne solviĝas, aspektas kiel nomo, kiu ne ekzistas, sed la adreso estas la problemo: du adaptiloj nun postulas 192.168.1.0/24 kaj nur unu itinero povas gajni tiun prefikson. Sekvu ĝin laŭ tiu ordo kaj vi vidos, kiu adaptilo prenis ĝin, antaŭ ol vi ŝanĝos ion ajn.
Komencu ĉe la simptomo, ne ĉe la tunelo
La signo estas la amplekso. Se la intraneto funkcias kaj ĉiu loka aparato malsukcesas, la tunelo sanas kaj la loka vojo ne. Se lokaj aparatoj funkcias kaj la intraneto malsukcesas, inverse. Se ĉio funkcias krom unu gastigo, vi rigardas unu adreson, kiu ekzistas ambaŭflanke.
Notu unu lokan kaj unu malproksiman adreson antaŭ ol tuŝi agordon. “La printilo” ne estas testebla; 192.168.1.40 estas. Tiu unu paŝo malhelpas la plej oftajn perditajn horojn ĉe ĉi tiu problemo, nome reverki DNS-agordojn pro decido pri enkursigo.
Paŝo 1: vidu ambaŭ adaptilojn postulantaj la prefikson
Malfermu Retajn Konektojn (ncpa.cpl) kaj legu la du adaptilojn flanke al flanke. La Ethernet-adaptilo montras 192.168.1.50/24 kun pordego 192.168.1.1. La VPN-adaptilo montras 192.168.1.201/24, senditan de la servilo. Ambaŭ estas legitimaj, ambaŭ kredas, ke la prefikso estas on-link, kaj la stako tenos unu itineron por ĝi.
Get-NetIPAddress -AddressFamily IPv4 listigas la adresojn, kaj Get-NetIPInterface | Sort-Object InterfaceMetric montras la ordon, en kiu la stako uzos ilin. Tiu metrika kolumno estas la decido, kiun vi baldaŭ legos, do notu la nombrojn anstataŭ memori ilin.
Pruvu malmultekoste, ke la DNS-teorio malĝustas: Resolve-DnsName printer.office.lan redonas la saman adreson kiel hieraŭ. La nomo solviĝis; la pakaĵo poste eliris tra la malĝusta adaptilo. Du minutoj ĉi tie ŝparas posttagmezon en la agordoj de la solvilo.
Paŝo 2: legu la itineron, kiu fakte venkis
Find-NetRoute -RemoteIPAddress 192.168.1.40 presas la interfacon, la sekvan salton kaj la fonton, kiujn la stako uzus por tiu adreso. Traktu tiun eligon kiel la respondon, ne kiel aludon. route print -4 donas la tutan tabelon, kiam vi volas vidi, kiu ero perdis kaj kiom multe.
Specifeco venkas intencon. Sendita 192.168.0.0/25 venkas lokan 192.168.0.0/24, ĉar la prefikso estas pli longa, do 192.168.0.0 ĝis 192.168.0.127 eliras tra la tunelo, dum la supra duono restas loka. Duoniĝinta LAN malaperanta sen erarmesaĝo estas ĝusta konduto por tiu tabelo.
tracert -d 192.168.1.40 konfirmas ĝin de ekster la tabelo: se la unua salto estas tunela adreso anstataŭ via propra enkursigilo, la itinero estas la tuta historio. En Linux la sama demando estas ip route get 192.168.1.40, kiu presas fontadreson kaj aparaton en unu linio. Kiam la respondo nomas tun0, ĉesu rigardi la retumilon.
Paŝo 3: kontrolu la revenan vojon antaŭ ol kulpigi la klienton
Ĝusta antaŭena itinero ankoraŭ malsukcesas, se la malproksima flanko ne povas respondi. Kiam klienta LAN atingiĝas tra la tunelo, la pordego de tiu LAN devas scii, kie loĝas la tunela baseno: ip route add 10.8.0.0/24 via 192.168.1.12 sur tiu enkursigilo, kaj push “route 192.168.1.0 255.255.255.0” de la servilo, por ke klientoj sciu la revenan vojon.
Sen la unua ero la respondo forlasas la celon al sia defaŭlta pordego, kiu plusendas privatan adreson al la provizanto kaj forĵetas ĝin. La simptomo estas unudirekta kaj facile mislega: petoj aperas sur tun0, respondoj neniam.
Masquerade-regulo sur la VPN-gastigo forigas la bezonon de tiu statika itinero: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ĝi ankaŭ kaŝas la realajn fontadresojn, kio malfaciligas ĉiun postan demandon pri protokoloj. Cela gastigo kun malĝusta defaŭlta pordego produktas la saman silenton, kun ICMP-alidirektigo kiel la plej bona kazo kaj nigra truo kiel la normala, tial la kaptado apartenas al ambaŭ finoj.
Paŝo 4: elektu riparon, kun kiu vi povas vivi
Por tio uziĝas kvin riparoj, kaj ili ne estas interŝanĝeblaj. Elektu laŭ tio, kio devas resti atingebla samtempe, ne laŭ tio, kiu komando estas la plej mallonga.
| 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 |
Metrikoj estas la malmultekosta opcio kaj tiu, al kiu homoj unue etendas la manon. La ŝanĝo validas por la interfaco, do ĝi funkcias dum la tunelo staras, kaj ĝi apartenas al skripto apud la kliento, ne al ŝelo, kiun vi forgesos. Ĝi ne povas doni samtempan aliron al la sama adreso en du retoj, kaj tio estas la limo, kiu sendas ĉiujn aliajn malsupren laŭ la tabelo.
Renumerigi la hejman LAN al 10.10.0.0/24 estas la pura solvo: unu renovigo de DHCP-luo plus la rezervoj, printilaj vicoj kaj malmole koditaj adresoj, kiuj mencias la malnovan intervalon. Renumerigi la ofican flankon kutime ne estas via decido. IPv6 tute forigas la kolizion, kiam ambaŭ retoj portas ĝin, uzante unikan lokan prefikson el fd00::/8 anstataŭ io memorebla, sed testu la aplikaĵon per TCP, ne per ping, ĉar ICMP povas funkcii dum la servo ne.
La propra traduk-opcio de OpenVPN estas la lasta rimedo, sendita de la servilo en klient-specifan dosierujan eron. Ĝi prenas kvar parametrojn post la opcia nomo — direkton, reton, retmaskon kaj alinomon — kaj la alinomo ne estas laŭvola: push "route 192.168.2.0 255.255.255.0" kaj push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". La reto kaj la masko estas la intervalo, kiun la kliento vidas (192.168.2.0/24), la alinomo estas la reala ofica intervalo ĉe la servila flanko (192.168.1.0/24), kaj la sendita itinero estas tio, kio igas tiun videblan intervalon atingebla. La ofico tiam aperas al tiu kliento sub 192.168.2.x. Dokumentu la mapadon en la profilo, alie la sekva persono sencimigos ĝin kiel enkursigan fuŝon.
Publikigi unu solan servon estas la mallarĝa versio de traduko kaj tute ne bezonas la opcion de OpenVPN. DNAT-regulo sur la VPN-gastigo republikigas unu pordon, do la LAN konservas siajn adresojn kaj atingas la servon ĉe la gastiga adreso, kiun ĝi jam konas. La kosto estas la kutima: la servo vidas la VPN-gastigon kiel fonton, do protokoloj laŭ kliento kaj inversaj serĉoj ĉesas signifi ion. Tio kovras unu printilan vicon aŭ unu administran paĝon, ne gastigojn ambaŭflanke, kiuj atingas unu la alian.
Kio ankoraŭ ne funkcios, kaj kion noti
Dissendo ne transiras enkursigitan tunelon. DLNA, UPnP, NetBIOS-brosado kaj Wake-on-LAN dependas de dissendo aŭ multdissendo, kiun tun-aparato ne portas, do neniu itinero riparas malkovron. Pontado per dev tap etendas la segmenton, kaj kun ĝi DHCP-dissendojn, ARP kaj ĉiun alian malkovran pakaĵon; preferu unudirektan gastigan itineron kiel route 192.168.2.1 255.255.255.255 por la LAN-flanka adreso de malproksima enkursigilo.
Du enkursigiloj, kiuj ambaŭ uzas 192.168.1.1 sur la sama vojo, apartenas al la sama familio de problemoj: la loka adreso ĉiam venkas, do la paĝo de la malproksima enkursigilo restas neatingebla, ĝis unu LAN transloĝiĝas. Aldoni duan adaptilon ŝanĝas nenion en iu ajn el la du kazoj.
Registru la pruvojn antaŭ ol redakti ion: ip route get aŭ Find-NetRoute, ping -c 3 al la koncerna adreso, traceroute, kaj tcpdump -ni tun0 icmp sur la kliento, poste la enkursiga tabelo kaj NAT-nombradoj sur la servilo. Ping, kiu funkcias unudirekte kaj mortas alidirekte, montras la revenan vojon, ne la tunelon, kaj ĝuste tiu distingo decidas, kiun el la supraj riparoj vi vere bezonas.