Одговорот на VPN меѓу локации не оди низ тунелот

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

Двете насоки се рутираат одделно

IP не памти насока на разговор. Секој домаќин што испраќа пакет го извршува своето пребарување на најдолгиот префикс, избира еден следен скок и ја заборава одлуката. Барањето и одговорот се два неповрзани пакети што случајно припаѓаат на истата врска, а тунелот е еден скок што секој од нив може да го користи или не. Ништо во размената IKE не го учи далечниот сервер како да стигне до вашата подмрежа; преговорите само се договараат кои префикси смеат да се шифрираат.

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

Далечниот домаќин не знае ништо за вашиот тунел

Во далечната локална мрежа одговорот е обичен пакет упатен до вашиот клиент. Одредишниот домаќин не гледа никаков IPsec заглавие и нема причина да ја претпочита VPN портата; го бара вашиот префикс, не наоѓа ништо поконкретно од својата стандардна рута и ја следи. Ако стандардната покажува на јадрена заштитна ѕид, таа или има рута назад во тунелот или нема. Кога нема, добивате тивко отфрлање, ICMP unreachable или одговор што излегува низ интерфејсот кон интернет и умира.

Втор интерфејс е доволен да го скрши ова дури и кога рута постои. NAS со управувачка врска на друг VLAN, сервер со резервен uplink, правило за политика што испраќа еден опсег извори во втора табела: било што од ова може да го фати одговорот. На Linux, ip rule show и ip route show table all ги покажуваат правилата и табелите што стандардниот список ги крие.

Прочитајте ја одлуката на машината што го испраќа одговорот

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

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Излезот ги наведува излезниот интерфејс и следниот скок. Ако интерфејсот не е тој што гледа кон VPN портата, го најдовте дефектот, а останатата работа е да изберете каде припаѓа рутата. Ping од портата овде докажува малку: одговара со адреса што далечниот домаќин може да ја смести, не со адресата на вашиот преносен сметач.

На Windows еквиваленти се Find-NetRoute -RemoteIPAddress 10.10.5.10 за одлуката и Get-NetRoute за табелата. Рута додадена со New-NetRoute што носи повисока метрика од стандардната губи тивко, затоа читајте ја колоната со метрика, не записот. Потоа потврдете со пакети: tcpdump -ni any "host 10.10.5.10 and tcp port 445" на далечниот LAN интерфејс го покажува барањето, а истиот филтер од страната на тунелот покажува дали се вратил одговор. Барање видливо без одговор значи дека одговорот е рутиран на друго место или отфрлен; одговор на погрешниот интерфејс ви го дава виновникот пред да допрете рута.

Кога портата на серверот не е крајна точка на VPN

Многу локации ставаат заштитен ѕид меѓу серверите и концентраторот. Тој ѕид го препраќа одговорот, затоа му треба рута за префиксот на вашиот клиент кон VPN портата и политика за препраќање во двете насоки. Уредите со состојба го влошуваат: барањето помина низ ѕидот од LAN домаќин што го дозволи, одговорот сега доаѓа од друга насока, и записот за следење на врската повеќе не се совпаѓа, па пакетот се отфрла како невалиден наместо како забранет. Затоа дневникот за политика изгледа празен додека сообраќајот исчезнува.

Портата има свој втор филтер. Обратното филтрирање на патека во Linux ги отфрла пакетите чиј извор не е достапен преку интерфејсот низ кој пристигнале, а тоа е токму формата на законска асиметрична повратна патека. упатството на strongSwan за препраќање бара net.ipv4.ip_forward и олеснет net.ipv4.conf.all.rp_filter токму поради тоа. Строга вредност 1 на која било порта тивко крши исправна рута, и nstat -az ги покажува отфрлањата ако знаете каде да гледате.

Рутирајте или преведете, потоа потврдете во двете насоки

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

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Изберете го свесно: штом клиентите почнат да се појавуваат како адреса на портата, ACL засновани на извор престануваат да ги разликуваат, и conntrack мора да го држи мапирањето за да се препише одговорот назад во тунелот. Ако селекторите сѐ уште го исклучуваат префиксот на клиентот, NAT не менува ништо, зашто барањето никогаш не влегло во тунелот.

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