Еднопосочен трафик след изключване на SNAT за подмрежа на Tailscale

Изключете изходния 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 за подмрежата е изключен. Разделянето на тези роли на различни възли премахва това предупреждение и дава на всеки маршрут и правило на защитната стена един собственик. Ако ролите трябва да останат заедно, очаквайте това поведение и го тествайте, преди да обвинявате клиент. Пазете маршрута, настройката на превключвателя и разпределението на ролите в една бележка, защото те се четат заедно, когато следващата връзка се провали.