Целосен тунел или рута до крајната точка: како да го одржиме VPN серверот достапен

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

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

Внатрешниот и надворешниот сообраќај се различни одлуки

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

Двете се одлуки за рутирање, и само првата му припаѓа на тунелот. Кога клиентот инсталира стандардна рута што го покрива и серверот, надворешниот пакет исто така се фаќа.

Симптомите се моментални и целосни. Ракувањето завршува и потоа ништо не тече, или врската паѓа во моментот кога се инсталира рутата. Во двата случаи keepalive веќе не може да излезе.

Прва опција: рута до домаќин за крајната точка

Директниот пристап додава рута за адресата на серверот преку првобитната порта. За тоа е потребна една линија. Таа е видлива за секој што ја чита табелата. Исто така е лесно да се објасни во запис за промена.

Неговата слабост се појавува кога основната патека се менува. Зачуваната рута именува порта и интерфејс од старата мрежа. По промена на Wi-Fi таа порта може да не постои, а рутата останува, изгледа исправно и не прави ништо.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

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

Втора опција: заштита на сокетот

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

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

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

Избор меѓу двете

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

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

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