Зошто вашата јавна Linux услуга одговара преку VPN

Ништо во сокетот не памети кој интерфејс го пренел барањето, така што стандардната рута на VPN со целосен тунел може да зароби одговор што му припаѓа на WAN. Услугата не го игнорира влезниот интерфејс; Linux рутира локално генериран одговор според одредиштето и политиката за извор. Правило засновано на извор може наместо тоа да ги испраќа само одговорите на услугата преку целосна WAN табела, оставајќи го вообичаениот излез на тунелот. Портата останува отворена додека одговорот излегува по погрешната патека, и затоа симптомот изгледа еднострано.

Погрешната претстава: одговорите го следат интерфејсот на кој пристигнале

Изгледа логично пакетот што пристигнува на eth0 да излезе на eth0. Филтрите на пакети без состојба можат така да се напишат, а tcpdump од влезната страна го покажува барањето точно онаму каде што се очекува. Рутирањето не функционира така за сообраќајот што сам го создава домаќинот.

Откако услугата ќе го прифати врската, нејзиниот одговор е нов локално генериран пакет. Јадрото ги проверува правилата за рутирање за одредиштето и изворот на одговорот, а стандардната рута на VPN е сосема валиден одговор. Ништо во сокетот не памети кој интерфејс го пренел барањето.

Затоа симптомот изгледа еднострано: барањата пристигнуваат, одговорите исчезнуваат. Затоа и додавањето правило на огнениот ѕид за влезната порта не менува ништо. Пакетот не се блокира на патот навнатре; тој се рутира на друго место на патот нанадвор. Следете го одговорот со пребарување определено по извор и обиколницата ќе стане видлива.

Што всушност рутира јадрото: изворната адреса

Рачката што ви треба е локалната адреса што услугата ја користи за одговори. На домаќин со илустративна eth0 адреса 192.0.2.10/24 и порта 192.0.2.1, таа адреса е присутна на интерфејсот. На облачен VM јавната адреса може да е преведена погоре и да отсуствува во гостинот, затоа користете ја адресата што домаќинот навистина ја има.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

Изградете целосна табела за враќање, не половина стандардна рута

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Користете го вистинскиот префикс и порта наместо да го копирате примерот. Облачен интерфејс конфигуриран како /32 со порта на врската бара друга поврзана рута, а табела изградена од погрешен префикс пропаѓа на првиот скок. Атрибутот src го наведува претпочитаниот извор за таа рута; тој не го заменува правилото за извор.

Редоследот исто така е важен. Широко правило со понизок број на приоритет се оценува прво, па до правилото за извор мора да се стигне пред кое било правило што би го вратило овој сообраќај во главната табела. Проверете ги приоритетите со ip rule show по додавањето, не само при подигање.

Проверете со пребарување определено по извор

Побарајте од јадрото да рутира тест одредиште од адресата на услугата. Одговорот треба да ги именува eth0 и WAN портата, не тунелот:

ip -4 route get 198.51.100.25 from 192.0.2.10

Потоа воспоставете нова овластена врска и набљудувајте ги двата правци. Пребарување што ја избира вистинската табела додека живата врска се уште пропаѓа укажува на филтрирање на обратната патека или правило на огнениот ѕид, не на табелата. Проверете ги тие контроли пред да исклучите нешто глобално.

Ставете ги конечните рути и правилото под мрежниот менаџер што го поседува интерфејсот. Промените на адресата, обновувањето на DHCP и повторните поврзувања на VPN ја препишуваат состојбата на јадрото, а правилото додадено рачно исчезнува или покажува на застарена порта по следниот настан.

Каде запира ова исклучок

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

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

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

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