Исклучете го изворниот NAT на рутерот за подмрежа на Tailscale и тунелот продолжува да работи додека врските низ него престануваат. Барањата пристигнуваат до одредиштето со сопствената overlay адреса на оддалечениот клиент, што е токму смислата на промената, и одговорите сега бараат пат што LAN никогаш не требало да го знае. Без тој пат пакетите слетуваат, одговорите излегуваат низ обичната порта, а дефектот се појавува како проблем со огнен ѕид што ниту едно правило не го објаснува. Тунелот е здрав; повратниот дел недостига.

Што криеше SNAT

Кога SNAT е вклучен, рутерот ја препишува изворната адреса на сопствената LAN адреса пред да пренесе во подмрежата, па одредиштето одговара на домаќин до кој веќе знае како да стигне и ништо друго не треба да се конфигурира. Исклучувањето го зачувува оригиналниот извор, а одредиштето тогаш гледа адреса во опсегот на overlay, а не сосед на сопствениот кабел. Таа адреса е вистинска и достапна за рутирање низ tailnet, но е недостапна од LAN преку стандардната порта. Документираниот прекинувач е --snat-subnet-routes=false, применет на самиот Linux рутер за подмрежа.

Тоа е постојано поставување, а не прекинувач за секој пакет, затоа повратниот пат мора да постои за секоја целна мрежа што ја опслужува тој рутер. Токму тоа ја прави промената одлука за распоредување наместо квадратче за потврда. Сѐ што го опслужува тој рутер ја наследува обврската во истиот момент.

Каде може да живее повратниот пат

Три поставувања се вообичаени и се разликуваат по дофат, а не по точност. Статичен маршрут на целниот домаќин е најдиректен и најмалку скалабилен, бидејќи секој уред бара своја копија. Табелата за рутирање во VPC или во рутерот на локацијата покрива цела мрежа одеднаш, а DHCP опцијата со безкласни статични маршрути стигнува до клиентите автоматски, но тивко пропаѓа на уредите што ја игнорираат.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Кое и поставување да изберете, следниот скок е LAN адресата на рутерот и никогаш неговата tailnet адреса. LAN домаќинот не може да го достигне overlay додека не ја има оваа рута, затоа следниот скок во overlay е кружен и не го испраќа пакетот никаде. Оваа единствена грешка ги објаснува повеќето конфигурации што изгледаат правилно и сепак пропаѓаат, и таа преживува секоја проверка што ја чита само табелата на самиот рутер. Запишете кое поставување го користевте, инаку следниот човек ќе го тестира погрешното.

Читање на дефектот како еднонасочен сообраќај

Симптомот е полесно да се препознае од причината: услугата одговара на самиот рутер и молчи од оддалечен клиент. Снимањето на одредиштето покажува барања што пристигнуваат и одговори што заминуваат, што изгледа како успех сѐ додека не забележите каде одат тие одговори. Тие одат кон стандардната порта, што значи дека влезниот дел работел, а повратниот не.

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Вреди ли вистинската адреса за рута

Задржувањето на SNAT останува поедноставен одговор кога целната мрежа не може повторно да се конфигурира, а цената е што секој клиент изгледа како рутерот во записите и политиката на одредиштето. Исклучувањето е оправдано кога апликацијата бара вистинската изворна адреса или кога мрежната политика треба да разликува клиенти што делат рутер. Двете се легитимни причини и ниту една не е бесплатна. Користа мора да вреди да се одржува рута во секоја целна мрежа, плус прегледот на огнениот ѕид опишан подолу.

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

Огнен ѕид, евидентирање и двојната улога

Секое правило што се совпаѓаше со LAN адресата на рутерот сега се совпаѓа со различен извор, вклучувајќи правила за дозвола и секое поле во записот што го евидентирало рутерот како клиент. Прочитајте ги тие правила пред првиот тест, а не по првиот неуспех, бидејќи правилото што дозволува само адресата на рутерот целосно го блокира новиот извор. Ограничете ја замената на клиентите и портите на кои им е потребна, потоа потврдете дека таа тивко не го пушта целиот tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Еден јазол што служи и како излезен јазол и како рутер за подмрежа е документирана комбинација што може да отфрли нагорен сообраќај откако SNAT на подмрежата е исклучен. Одвојувањето на тие улоги на различни јазли ја отстранува таа забелешка и ѝ дава на секоја рута и политика на огнен ѕид еден сопственик. Ако улогите мора да останат заедно, очекувајте такво однесување и тестирајте го пред да го обвините клиентот. Чувајте ги рутата, поставката на прекинувачот и доделувањето на улогите во една белешка, бидејќи тие се читаат заедно кога следната врска ќе пропадне.

Поврзани статии