Мост-поврзани OpenVPN клиенти без интернет? Проверете го NAT правилото

Мост-поврзаниот сервер е активен, masquerade правилото е присутно, а прелистувачот на клиентот сè уште врти. Сè изгледа како да треба да работи, и токму затоа првиот час се троши на проверка на тунелот и на акредитивите. Потоа го читате бројачот на NAT правилото и наоѓате нула што не е поместена. Правило што никогаш не изброило ниту еден пакет никогаш не ни се совпаднало, а на мост-поврзан сервер причината е структурна: клиентскиот сообраќај излегува преку виртуелниот tap уред, додека правилото ја именува физичката карта што сте ја прекопирале од постар водич.

Бројачот е доказот, не записот во табелата

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

iptables -t nat -L POSTROUTING -v -n

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

Најдете го името што кернелот навистина го запишува

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

ip -brief link

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

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

Читањето на forward синџирот со бројачи трае една команда и исклучува половина од преостанатите можности пред воопшто да допрете друго правило.

Зошто физичката карта никогаш не се совпаѓа

Мостот е софтверски прекинувач составен од tap уредот и еден физички интерфејс. Клиентската рамка влегува во тој прекинувач и излегува кон физичката мрежа како член на мостот, а не како пакет на картата. Затоа кернелот го припишува пакетот на мостот и неговиот порт, и затоа картата за која мислевте никогаш не се појавува во совпаѓањето. Ништо не е расипано на физичкиот интерфејс; тој едноставно не е уредот на кој кернелот му го припишува тој пакет.

Следниот проблем со кој луѓето се среќаваат доаѓа од истата структура: филтрирањето рамки на мост е одделна можност од IP филтрирањето. Ако барањето е ограничување на ниво на рамка, тоа припаѓа на филтрирањето на мостот, а не на правило од IP табелата.

Докажете го од почеток до крај, потоа трајно зачувајте го

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

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

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