По промена на IP адресата на серверот, SNAT правилото сѐ уште ја наведува старата

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

Поврзувањето и проследувањето откажуваат на различни места

Воспоставувањето зависи од крајната точка што клиентите веќе ја знаат: јавната адреса, проследувањето на порта пред неа и слушачот внатре. Проследениот сообраќај зависи од втора одлука донесена откако пакетот ќе влезе во тунелот, кога хостот го препишува својот извор за да можат одговорите да го најдат патот назад.

Промената на адресата крши само втората одлука, и затоа симптомот се чита како "поврзано, но без интернет". Тоа објаснува и зошто вообичаените проверки на страната на клиентот изгледаат здрави: ракувањето завршува, клиентот добива адреса, и дури ping до тунелската адреса на серверот може да одговори. Часови се трошат на клиентот поради дефект што живее на другата страна, затоа табелата со правила е првото место каде треба да се погледне.

Прочитајте го правилото и неговите бројачи пред да уредувате

Излистајте ги правилата за превод со бројачи и споредете го конфигурираниот извор со адресите што хостот навистина ги има. Правило препишано на мртва адреса обично покажува сообраќај на влезниот пат, бидејќи пакетите стигнуваат до него и се преведуваат, а на повратниот пат ништо.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

Ако бројачите стојат на нула, пакетите никогаш не стигнуваат до ова правило и адресата не е тековниот проблем. Побарајте конкурентно правило порано во синџирот, што се случува кога некој додава замена наместо да го уредува оригиналот. Споредете ги броевите на правилата со излезот што го запишавте пред една минута. Редоследот е дел од конфигурацијата, а не козметички детаљ.

Заменете го изворот, или престанете да наведувате еден

Кога хостот има стабилна адреса, заменете го правилото на местото, наместо да додавате уште едно. Замената по број на правило го сочувува редоследот од кој зависи остатокот од синџирот.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Потврдете дека проследувањето на IPv4 сѐ уште е овозможено преку управувана конфигурација, потоа направете го правилото трајно со сопствениот механизам на дистрибуцијата. Промена направена само во јадрото што работи се враќа со следното рестартирање, обично во прозорец за одржување што никој не го поврзува со промената.

Два начина да се направи замената погрешно

Преведувањето на базенот на тунелската адреса на серверот наместо на неговата LAN адреса ги праќа одговорите директно назад во тунелот, каде што се насочуваат кон клиент што никогаш не ги побарал. Врската застанува на начин што личи на јамка за насочување, бидејќи тоа и е.

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

Ако тунелот носи и IPv6, повторете го целиот преглед на другиот стек. Стандардната рута на IPv6 без превод и без насочен префикс откажува исто толку тивко, и лесно се заборава бидејќи сѐ над неа изгледа идентично.

Влезните услуги бараат обратен превод

Услуга на клиент на VPN што мора да биде достапна однадвор бара превод на одредиштето, не на изворот: јавната порта се препишува на тунелската адреса на клиентот пред да влезе. Потоа патот за проследување бара изречно правило што го дозволува тој сообраќај.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Никогаш не преведувајте ја портата што го носи самиот тунел, бидејќи тоа препишување ја прекинува врската што ја држи услугата достапна. Држете ја тунелската порта целосно надвор од правилата за одредиште. На крајот проверете од двата краја: бројачи на новото правило, краток запис на тунелскиот уред и едно барање до адреса внатре во тунелот пред да ја пробате јавната.