VPN dhe LAN-i i shtëpisë në të njëjtën nënrrjetë: ndiqni së pari rrugën
Të dy përshtatësit kërkojnë 192.168.1.0/24 dhe fiton vetëm një rrugë. Ndiqni listën e përshtatësve, rrugën fituese dhe rrugën e kthimit përpara se të rinumeroni ose të fajësoni DNS-në.
Lidheni me VPN-në e zyrës, ikona në tabaka bëhet e gjelbër, intraneti ngarkohet dhe printeri dy metra larg ndalon së përgjigjuri. Ndarija që punonte në mëngjes skadon në të njëjtën makinë, dhe asnjë regjistër nuk përmend printer. Refleksi është DNS, sepse një emër që nuk zgjidhet duket si emër që nuk ekziston, por problemi është adresa: dy përshtatës tani kërkojnë 192.168.1.0/24 dhe vetëm një rrugë mund ta fitojë atë prefiks. Ndjekeni në këtë rend dhe do të shihni cili përshtatës e mori përpara se të ndryshoni gjë.
Filloni nga simptoma, jo nga tuneli
Treguesi është shtrirja. Nëse intraneti punon dhe çdo pajisje lokale dështon, tuneli është i shëndoshë dhe rruga lokale nuk është. Nëse pajisjet lokale punojnë dhe intraneti dështon, e kundërta. Nëse gjithçka punon përveç një hosti, po shihni një adresë të vetme që ekziston në të dyja anët.
Shkruani një adresë lokale dhe një të largët përpara se të prekni ndonjë cilësim. „Printeri“ nuk mund të testohet; 192.168.1.40 mundet. Ky hap i vetëm parandalon orën më të humbur të zakonshme në këtë problem, domethënë rishkrimin e cilësimeve të DNS për një vendim rrugëtimi.
Hapi 1: shihni të dy përshtatësit që kërkojnë prefiksin
Hapni Lidhjet e Rrjetit (ncpa.cpl) dhe lexoni të dy përshtatësit krah për krah. Përshtatësi Ethernet tregon 192.168.1.50/24 me portë 192.168.1.1. Përshtatësi VPN tregon 192.168.1.201/24, dërguar nga serveri. Të dy janë legitimë, të dy besojnë se prefiksi është on-link, dhe stiva do të mbajë një rrugë të vetme për të.
Get-NetIPAddress -AddressFamily IPv4 liston adresat, dhe Get-NetIPInterface | Sort-Object InterfaceMetric tregon rendin në të cilin stiva do t'i përdorë ato. Ai kolonë metrike është vendimi që po lexoni, prandaj shkruani numrat në vend që të përpiqeni t'i mbani mend.
Përgënjeshtroni lirë teorinë e DNS: Resolve-DnsName printer.office.lan kthen të njëjtën adresë si dje. Emri u zgjidh; më pas paketa doli nga përshtatësi i gabuar. Dy minuta këtu kursejnë një pasdite në cilësimet e zgjidhësit.
Hapi 2: lexoni rrugën që fitoi vërtet
Find-NetRoute -RemoteIPAddress 192.168.1.40 shtyp ndërfaqen, kërcimin tjetër dhe burimin që stiva do të përdorte për atë adresë. Trajtoni këtë dalje si përgjigjen, jo si një aluzion. route print -4 jep të gjithë tabelën kur doni të shihni cila hyrje humbi dhe sa.
Specifikimi mund qëllimin. Një 192.168.0.0/25 i shtyrë mposht një 192.168.0.0/24 lokal sepse prefiksi është më i gjatë, prandaj 192.168.0.0 deri 192.168.0.127 dalin përmes tunelit ndërsa gjysma e sipërme mbetet lokale. Zhdukja e gjysmës së LAN-it pa mesazh gabimi është sjellja e saktë për atë tabelë.
tracert -d 192.168.1.40 e konfirmon nga jashtë tabelës: nëse kërcimi i parë është një adresë tuneli në vend të ruterit tuaj, rruga është e gjithë historia. Në Linux e njëjta pyetje është ip route get 192.168.1.40, që shtyp adresën e burimit dhe pajisjen në një rresht. Kur përgjigjja përmend tun0, ndaloni së shikuari shfletuesin.
Hapi 3: kontrolloni rrugën e kthimit përpara se të fajësoni klientin
Një rrugë e saktë përpara dështon gjithsesi nëse ana e largët nuk mund të përgjigjet. Kur arrihet një LAN klienti përmes tunelit, porta e atij LAN-i duhet ta dijë ku jeton pishina e tunelit: ip route add 10.8.0.0/24 via 192.168.1.12 në atë ruter, dhe push „route 192.168.1.0 255.255.255.0“ nga serveri që klientët ta dinë rrugën e kthimit.
Pa hyrjen e parë përgjigjja largohet nga objektivi drejt portës së saj të paracaktuar, e cila përcjell një adresë private te ofruesi dhe e hedh atë. Simptoma është njëdrejtimëshe dhe lexohet lehtë gabim: kërkesat shfaqen në tun0, përgjigjet kurrë.
Një rregull masquerade në hostin VPN heq nevojën për atë rrugë statike: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ai fsheh edhe adresat e vërteta të burimit, gjë që e bën çdo pyetje të mëvonshme për regjistrat më të vështirë. Një host objektiv me portë të paracaktuar të gabuar prodhon të njëjtin heshtje, me një ridrejtim ICMP në rastin më të mirë dhe një vrimë të zezë në atë normal, prandaj kapja i takon të dy skajeve.
Hapi 4: zgjidhni një rregullim me të cilin mund të jetoni
Për këtë përdoren pesë rregullime dhe ato nuk janë të këmbyeshme. Zgjidhni sipas asaj që duhet të mbetet e arritshme në të njëjtën kohë, jo sipas asaj se cila komandë është më e shkurtër.
| 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 |
Metrikat janë opsioni i lirë dhe ai që njerëzit kapin së pari. Ndryshimi vlen për ndërfaqen, prandaj punon sa kohë tuneli është lart, dhe vendi i tij është në një skript pranë klientit, jo në një shell që do ta harroni. Ai nuk mund të japë akses të njëkohshëm në të njëjtën adresë në dy rrjete, dhe pikërisht ky kufi i dërgon të gjithë të tjerët poshtë tabelës.
Rinumerimi i LAN-it të shtëpisë në 10.10.0.0/24 është zgjidhja e pastër: një rinovim i qirasë DHCP plus rezervimet, radhët e printimit dhe adresat e koduara që përmendin intervalin e vjetër. Rinumerimi i anës së zyrës zakonisht nuk është vendimi juaj. IPv6 e eliminon plotësisht përplasjen kur të dy rrjetet e mbajnë, duke përdorur një prefiks lokal unik nga fd00::/8 në vend të diçkaje të paharrueshme, por testoni aplikacionin përmes TCP, jo me ping, sepse ICMP mund të punojë ndërsa shërbimi jo.
Opsioni i vetë përkthimit i OpenVPN është mjeti i fundit, i shtyrë nga serveri në një hyrje drejtorie specifike për klientin. Ai merr katër parametra pas emrit të opsionit — drejtimin, rrjetin, maskën dhe aliasin — dhe aliasi nuk është opsional: push "route 192.168.2.0 255.255.255.0" dhe push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Rrjeti dhe maska janë intervali që sheh klienti (192.168.2.0/24), aliasi është intervali i vërtetë i zyrës në anën e serverit (192.168.1.0/24), dhe rruga e shtyrë është ajo që e bën të arritshëm atë interval të dukshëm. Zyra atëherë i shfaqet atij klienti nën 192.168.2.x. Dokumentoni hartëzimin në profil, përndryshe personi tjetër do ta korrigjojë si defekt rrugëtimi.
Publikimi i një shërbimi të vetëm është versioni i ngushtë i përkthimit dhe nuk ka fare nevojë për opsionin e OpenVPN. Një rregull DNAT në hostin VPN ripublikon një port të vetëm, kështu që LAN-i ruan adresat e tij dhe e arrin shërbimin në adresën e hostit që tashmë e njeh. Kostoja është ajo e zakonshme: shërbimi e sheh hostin VPN si burim, prandaj regjistrat për klient dhe kërkimet e kundërta nuk nënkuptojnë më asgjë. Kjo mbulon një radhë printimi ose një faqe administrimi, jo hoste në të dyja anët që arrijnë njëri-tjetrin.
Çka nuk do të punojë ende dhe çka duhet të regjistrohet
Transmetimi nuk kalon një tunel të rrugëtuar. DLNA, UPnP, shfletimi NetBIOS dhe Wake-on-LAN varen nga transmetimi ose multicast-i që një pajisje tun nuk e mbart, prandaj asnjë rrugë nuk e rregullon zbulimin. Lidhja me urë me dev tap e zgjeron segmentin, dhe bashkë me të transmetimet DHCP, ARP dhe çdo paketë tjetër zbulimi; preferoni një rrugë hosti unicast si route 192.168.2.1 255.255.255.255 për adresën e anës LAN të një ruteri të largët.
Dy ruter që të dy përdorin 192.168.1.1 në të njëjtën rrugë i përkasin të njëjtës familje problemi: adresa lokale fiton gjithmonë, prandaj faqja e ruterit të largët mbetet e paarritshme derisa një LAN të zhvendoset. Shtimi i një përshtatësi të dytë nuk ndryshon asgjë në asnjë nga të dyja rastet.
Regjistroni provat përpara se të modifikoni gjë: ip route get ose Find-NetRoute, ping -c 3 te adresa në fjalë, një traceroute, dhe tcpdump -ni tun0 icmp në klient, pastaj tabela e rrugëtimit dhe numëruesit NAT në server. Një ping që punon në një drejtim dhe vdes në tjetrin tregon rrugën e kthimit, jo tunelin, dhe pikërisht ky dallim i vetëm vendos se cili nga rregullimet më sipër ju nevojitet vërtet.