VPN и домашната LAN во иста подмрежа: прво следете ја рутата

Се поврзувате со канцеларискиот VPN, иконата во системската лента станува зелена, интранетот се вчитува, а печатачот на два метра престанува да одговара. Споделената папка што работеше наутро истекува на истиот компјутер, и ниту еден дневник не споменува печатач. Првата реакција е DNS, бидејќи име што не се решава изгледа како име што не постои, но проблемот е во адресата: два адаптера сега претендираат на 192.168.1.0/24 и само една рута може да го добие тој префикс. Следете го по овој ред и ќе видите кој адаптер го зеде пред да промените нешто.

Започнете од симптомот, не од тунелот

Знакот е обемот. Ако интранетот работи и секој локален уред не успева, тунелот е здрав, а локалниот пат не е. Ако локалните уреди работат и интранетот не успева, обратно. Ако сето работи освен еден домаќин, гледате една адреса што постои од двете страни.

Запишете една локална и една оддалечена адреса пред да допрете поставка. „Печатачот“ не може да се тестира; 192.168.1.40 може. Овој еден чекор го спречува најчесто губењето час на овој проблем, односно препишување на DNS поставките поради одлука за рутирање.

Чекор 1: видете ги двата адаптера што претендираат на префиксот

Отворете Мрежни врски (ncpa.cpl) и прочитајте ги двата адаптера еден до друг. Ethernet адаптерот покажува 192.168.1.50/24 со порта 192.168.1.1. VPN адаптерот покажува 192.168.1.201/24, испратен од серверот. Двата се легитимни, двата веруваат дека префиксот е on-link, и стекот ќе чува една рута за него.

Get-NetIPAddress -AddressFamily IPv4 ги набројува адресите, а Get-NetIPInterface | Sort-Object InterfaceMetric го покажува редот по кој стекот ќе ги користи. Таа колона со метрика е одлуката што штотуку ја читате, затоа запишете ги броевите наместо да се обидувате да ги запаметите.

Докажете ефтино дека теоријата за DNS е погрешна: Resolve-DnsName printer.office.lan ја враќа истата адреса како вчера. Името се реши; потоа пакетот излезе низ погрешниот адаптер. Две минути овде заштедуваат попладне во поставките на решавачот.

Чекор 2: прочитајте ја рутата што навистина победи

Find-NetRoute -RemoteIPAddress 192.168.1.40 го печати интерфејсот, следниот скок и изворот што стекот би ги користел за таа адреса. Третирајте го овој излез како одговор, не како навестување. route print -4 ја дава целата табела кога сакате да видите кој запис загуби и колку.

Специфичноста победува намера. Испратената 192.168.0.0/25 ја победува локалната 192.168.0.0/24 затоа што префиксот е подолг, па 192.168.0.0 до 192.168.0.127 излегуваат низ тунелот, додека горната половина останува локална. Тоа што половина LAN исчезнува без порака за грешка е правилно однесување за таа табела.

tracert -d 192.168.1.40 го потврдува тоа однадвор од табелата: ако првиот скок е адреса на тунел наместо вашиот сопствен рутер, рутата е целата приказна. На Linux истото прашање е ip route get 192.168.1.40, што ја печати изворната адреса и уредот во еден ред. Кога одговорот ќе го наведе tun0, престанете да гледате во прелистувачот.

Чекор 3: проверете го повратниот пат пред да го обвините клиентот

Правилна рута напред сепак не успева ако далечната страна не може да одговори. Кога до LAN на клиент се доаѓа низ тунелот, портата на таа LAN мора да знае каде живее базенот на тунелот: ip route add 10.8.0.0/24 via 192.168.1.12 на тој рутер, и push „route 192.168.1.0 255.255.255.0“ од серверот за клиентите да го знаат повратниот пат.

Без првиот запис одговорот ја напушта целта кон својата стандардна порта, која проследува приватна адреса до давателот и ја отфрла. Симптомот е еднонасочен и лесно се чита погрешно: барањата се појавуваат на tun0, одговорите никогаш.

Правило masquerade на VPN домаќинот ја отстранува потребата од таа статична рута: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Тоа ги крие и вистинските изворни адреси, што го отежнува секое подоцнежно прашање за дневниците. Целниот домаќин со погрешна стандардна порта го дава истиот молк, со ICMP пренасочување во најдобар случај и црна дупка во нормалниот, затоа снимањето им припаѓа на двата краја.

Чекор 4: изберете поправка со која можете да живеете

За ова се користат пет поправки и тие не се заменливи. Изберете според тоа што мора да остане достапно истовремено, а не според тоа која наредба е најкуса.

Метриките се евтиниот избор и тој по кој луѓето прво посегнуваат. Промената важи за интерфејсот, па работи додека тунелот е кренат, и ѝ е местото во скрипта до клиентот, а не во школка што ќе ја заборавите. Не може да даде истовремен пристап до иста адреса во две мрежи, и токму тоа ограничување ги праќа сите други по табелата надолу.

Пренумерирањето на домашната LAN на 10.10.0.0/24 е чистото решение: едно обновување на DHCP закупот плус резервациите, печатачките редици и тврдо кодираните адреси што го споменуваат стариот опсег. Пренумерирањето на канцелариската страна обично не е ваша одлука. IPv6 целосно го отстранува судирот кога двете мрежи го носат, користејќи единствен локален префикс од fd00::/8 наместо нешто што се памти, но тестирајте ја апликацијата преку TCP, не со ping, бидејќи ICMP може да работи додека услугата не.

Сопствената опција за превод на OpenVPN е последното средство, се испраќа од серверот во запис во директориумот специфичен за клиентот. По името на опцијата зема четири параметри — насока, мрежа, маска и псевдоним — и псевдонимот не е изборен: push "route 192.168.2.0 255.255.255.0" и push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Мрежата и маската се опсегот што клиентот го гледа (192.168.2.0/24), псевдонимот е вистинскиот канцелариски опсег на страната на серверот (192.168.1.0/24), а испратената рута го прави тој видлив опсег достапен. Тогаш канцеларијата на тој клиент му се прикажува под 192.168.2.x. Документирајте го мапирањето во профилот, инаку следниот човек ќе го дебагира како рутирачка грешка.

Објавувањето на една услуга е тесната верзија на преводот и воопшто не ѝ треба опцијата на OpenVPN. DNAT правило на VPN домаќинот објавува повторно еден порт, па LAN ги задржува своите адреси и ја достигнува услугата на адресата на домаќинот што веќе ја знае. Цената е вообичаената: услугата го гледа VPN домаќинот како извор, па дневниците по клиент и обратните пребарувања престануваат да значат нешто. Тоа покрива една печатачка редица или една административна страница, не домаќини од двете страни што се достигнуваат еден со друг.

Што нема да работи и понатаму, и што да запишете

Емитувањето не преминува маршрутиран тунел. DLNA, UPnP, прегледувањето NetBIOS и Wake-on-LAN зависат од емитување или мултикаст што tun уредот не го носи, па ниту една рута не го поправа откривањето. Мостот со dev tap го проширува сегментот, а со него DHCP емитувањата, ARP и секој друг пакет за откривање; претпочитајте unicast рута до домаќин, на пример route 192.168.2.1 255.255.255.255, за адресата од LAN страната на оддалечен рутер.

Два рутера што и двата користат 192.168.1.1 на иста патека припаѓаат на истото семејство проблеми: локалната адреса секогаш победува, па страницата на далечниот рутер останува недостапна додека една LAN не се премести. Додавањето втор адаптер не менува ништо во ниту еден од двата случаи.

Запишете ги доказите пред да уредите нешто: ip route get или Find-NetRoute, ping -c 3 до предметната адреса, traceroute, и tcpdump -ni tun0 icmp на клиентот, потоа рутирачката табела и NAT бројачите на серверот. Ping што работи во една насока и умира во другата покажува на повратниот пат, не на тунелот, и токму таа разлика одлучува која од поправките погоре ви е навистина потребна.