VPN en thúslan brûke deselde subnet: rin earst de rûte nei
Beide adapters easkje 192.168.1.0/24 en ien rûte wint. Rin de adapterlist, de winnende rûte en de weromwei nei foardat jo fernûmerje of DNS de skuld jouwe.
Jo ferbine mei de kantoar-VPN, it ikoan yn de taakbalke wurdt grien, it intranet laden en de printer twa meter fierder hâldt op mei antwurdzjen. De dielde map dy't fan 'e moarn wurke, rint op deselde masine op in time-out, en gjin inkeld loch neamt in printer. De refleks is DNS, want in namme dy't net oplost liket in namme dy't net bestiet, mar it adres is it probleem: twa adapters easkje no 192.168.1.0/24 en mar ien rûte kin dat foarheaksel winne. Rin it yn dizze folchoarder troch en jo sille sjen hokker adapter it naam hat foardat jo eat feroarje.
Begjin by it symptoom, net by de tunnel
It teken is berik. As it intranet wurket en elk lokaal apparaat falt ôf, is de tunnel sûn en it lokale paad net. As lokale apparaten wurkje en it intranet falt ôf, dan oarsom. As alles wurket útsein ien host, sjogge jo ien adres dat oan beide kanten bestiet.
Skriuw ien lokaal en ien ôfstân adres op foardat jo in ynstelling oanreitsje. “De printer” is net te testen; 192.168.1.40 wol. Dy iene stap foarkomt it meast foarkommende ferlerne oere by dit probleem, nammentlik it werom skriuwen fan DNS-ynstellingen foar in rûtebeslissing.
Stap 1: sjoch beide adapters it foarheaksel easkjen
Iepenje Netwurkferbiningen (ncpa.cpl) en lês de twa adapters njonkeninoar. De Ethernet-adapter toant 192.168.1.50/24 mei gateway 192.168.1.1. De VPN-adapter toant 192.168.1.201/24, troch de tsjinner stjoerd. Beide binne legitiem, beide leauwe dat it foarheaksel on-link is, en de stapel sil ien rûte dêrfoar hâlde.
Get-NetIPAddress -AddressFamily IPv4 listet de adressen op, en Get-NetIPInterface | Sort-Object InterfaceMetric toant de folchoarder wêryn't de stapel se brûke sil. Dy metrykkolom is de beslissing dy't jo op it punt steane te lêzen, dus skriuw de sifers op ynstee fan se te ûnthâlden.
Bewiis de DNS-teory goedkeap ferkeard: Resolve-DnsName printer.office.lan jout itselde adres werom as juster. De namme is oplost; it pakket gie doe troch de ferkearde adapter fuort. Twa minuten hjir besparje in middei yn resolver-ynstellingen.
Stap 2: lês de rûte dy't wier wûn
Find-NetRoute -RemoteIPAddress 192.168.1.40 prints it ynterface, de folgjende hop en de boarne dy't de stapel foar dat adres brûke soe. Behannelje dy útfier as it antwurd, net as in oanwizing. route print -4 jout de hiele tabel as jo sjen wolle hokker ynskriuwing ferlear en hoefolle.
Spesifisiteit ferslacht bedoeling. In stjoerde 192.168.0.0/25 ferslacht in lokale 192.168.0.0/24 om't it foarheaksel langer is, dus 192.168.0.0 oant 192.168.0.127 geane troch de tunnel fuort, wylst de boppeste helte lokaal bliuwt. In heal lan dat sûnder flaterberjocht ferdwynt is korrekt gedrach foar dy tabel.
tracert -d 192.168.1.40 befêstiget it fan bûten de tabel: as de earste hop in tunneladres is ynstee fan jo eigen router, dan is de rûte it hiele ferhaal. Op Linux is deselde fraach ip route get 192.168.1.40, dy't boarneadres en apparaat op ien rigel prints. As it antwurd tun0 neamt, hâld dan op mei nei de browser te sjen.
Stap 3: kontrolearje de weromwei foardat jo de kliïnt de skuld jouwe
In korrekte foarût-rûte mislearret dochs as de fiere kant net antwurdzje kin. As in kliïnt-lan troch de tunnel berikt wurdt, moat de gateway fan dat lan witte wêr't de tunnelpool wennet: ip route add 10.8.0.0/24 via 192.168.1.12 op dy router, en push “route 192.168.1.0 255.255.255.0” fan 'e tsjinner ôf sadat kliïnten de weromwei kenne.
Sûnder de earste ynskriuwing ferlit it antwurd it doel nei syn standertgateway, dy't in privee adres oan 'e provider trochjaan en falle lit. It symptoom is ienrjochting en maklik ferkeard te lêzen: oanfragen ferskine op tun0, antwurden nea.
In masquerade-regel op 'e VPN-host hellet de needsaak foar dy statyske rûte fuort: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. It ferberget ek de echte boarnealderessen, wat elke lettere lochfraach dreger makket. In doelhost mei de ferkearde standertgateway jout deselde stilte, mei in ICMP-omlieding as bêste gefal en in swart gat as normale gefal, en dêrom heart de opname oan beide kanten.
Stap 4: kies in reparaasje wêr't jo mei libje kinne
Hjirfoar wurde fiif reparaasjes brûkt, en se binne net útwikselber. Kies nei wat tagelyk berikber bliuwe moat, net nei hokker opdracht it koartst is.
| 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 |
Metryk is de goedkeape opsje en dejinge dêr't minsken earst nei gripe. De feroaring jildt foar it ynterface, dus it wurket wylst de tunnel omheech is, en it heart yn in skript njonken de kliïnt ynstee fan yn in shell dy't jo ferjitte sille. It kin gjin tagelyk tagong ta itselde adres op twa netwurken jaan, en dat is de beheining dy't alle oaren de tabel del stjoert.
It thúslan fernûmerje nei 10.10.0.0/24 is de skjinne oplossing: ien DHCP-leasefernieuwing plus de reservearrings, printerwachtrijen en hurdcodearre adressen dy't it âlde berik neame. It kantoarfernûmerjen is meastentiids net jo beslissing. IPv6 hellet de botsing hielendal fuort as beide netwurken it drage, mei in unyk lokaal foarheaksel út fd00::/8 ynstee fan eat dat te ûnthâlden is, mar test de applikaasje oer TCP, net mei in ping, want ICMP kin wurkje wylst de tsjinst dat net docht.
OpenVPN syn eigen oersettingsopsje is it lêste rêdmiddel, fan 'e tsjinner ôf yn in kliïnt-spesifike mapynskriuwing stjoerd. It nimt fjouwer parameters nei de opsjenamme — rjochting, netwurk, netmasker en alias — en de alias is net opsjoneel: push "route 192.168.2.0 255.255.255.0" en push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". It netwurk en it netmasker binne it berik dat de kliïnt sjocht (192.168.2.0/24), de alias is it echte kantoarberik oan 'e tsjinnerkant (192.168.1.0/24), en de stjoerde rûte is wat dat sichtbere berik berikber makket. It kantoar ferskynt dan foar dy kliïnt ûnder 192.168.2.x. Dokumintearje de mapping yn it profyl, oars sil de folgjende persoan it as in rûteflater debugge.
Ien tsjinst publisearje is de smelle ferzje fan oersette, en it hat hielendal gjin opsje fan OpenVPN nedich. In DNAT-regel op 'e VPN-host publisearret ien poarte opnij, sadat it lan syn adressen hâldt en de tsjinst berikt op it hostadres dat it al ken. De kosten binne de gewoane: de tsjinst sjocht de VPN-host as boarne, dus lochs per kliïnt en omkearde opsochten betsjutte neat mear. Dat dekt ien printerwachtrij of ien admin-side, net hosts oan beide kanten dy't elkoar berikke.
Wat dochs net wurkje sil, en wat jo fêstlizze moatte
Broadcast giet net oer in rûtearre tunnel. DLNA, UPnP, NetBIOS-broabjen en Wake-on-LAN hingje ôf fan broadcast of multicast dy't in tun-apparaat net draacht, dus gjin rûte reparearret ûntdekking. Bridging mei dev tap wreidet it segmint út, en dêrmei DHCP-broadcasts, ARP en elk oar ûntdekkingspakket; foarkar in unicast-hostrûte lykas route 192.168.2.1 255.255.255.255 foar it lan-kant-adres fan in fiere router.
Twa routers dy't beide 192.168.1.1 op itselde paad brûke, hearre by deselde famylje probleem: it lokale adres wint altyd, dus de side fan 'e fiere router bliuwt ûnberikber oant ien lan ferhuzet. In twadde adapter tafoegje feroaret neat oan ien fan beide gefallen.
Skriuw it bewiis op foardat jo eat bewurkje: ip route get of Find-NetRoute, ping -c 3 nei it adres yn kwestje, in traceroute, en tcpdump -ni tun0 icmp op 'e kliïnt, dan de rûtetabel en NAT-tellers op 'e tsjinner. In ping dy't ien kant op wurket en de oare kant dea giet, wiist nei de weromwei, net nei de tunnel, en dy iene ûnderskied beslút hokker fan 'e reparaasjes hjirboppe jo echt nedich hawwe.