Два VPN скока на еден Pi: која рута носи кој партнер

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

Три дестинации на кои им требаат различни носители

Синџирот од два скока е три класи на дестинации наредени една врз друга, и секоја ја носи различно поврзување. Надворешниот партнер мора да се достигне преку физичката врска. Внатрешниот партнер мора да се достигне преку надворешниот тунел. Дестинацијата на покриената апликација мора да се достигне преку внатрешниот тунел, чиј сопствен транспорт го носи надворешниот.

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

Адресите имаат улоги, не број

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

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

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

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

Редоследот на активирање победува фиксно чекање

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

Јадрото доделува имиња како tun0 и tun1 по редослед на создавање, и тој редослед може да се промени меѓу престартувања или повторни поврзувања. Врзете ја конфигурацијата за идентитет што го нуди алатката, или за име што свесно го доделувате. Името што го избирате е договор; името што го избира јадрото е случајност.

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

Што се случува кога надворешниот скок умира

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

Ако два скока се задолжителни, внатрешниот клиент не смее да може да воспостави директен пат кога надворешниот го нема, а начинот да се знае е да се скрши надворешниот скок и да се набљудува што прави внатрешниот. Одобрената резерва е легитимен одговор, но мора да биде напишана, тестирана и соопштена. Резерва што никој не ја документирал е неразлична од истекување при преглед на инцидент.

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

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

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

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