Сменивте маршрута или правило на огнениот ѕид за да тестирате тунел на рутерот, и сега страницата за администрација не одговара од преносниот компјутер што пред десет минути работеше исправно. Првиот одговор е да го обвините VPN-от. Најчесто тунелот е здрав и се расипало едно од три други нешта: нема маршрута назад кон сопствената адреса на рутерот, влезната политика го отфрла барањето или веб-услугата не слуша на адресата што ја повикувате. Сите три изгледаат исто во прелистувачот, затоа луѓето рестартираат тунел со час и не учат ништо.

Еве го митот што вреди прво да се убие: тунелот што работи не е пат назад внатре. Тој е нова мрежна врска со свои прашања за доверба и може тивко да ја отстрани старата административна патека додека отвора нова што никој не ја прегледал.

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

Пренасочувањето и влезот се различни работи. „Може ли клиент да стигне до NAS преку тунелот?“ е прашање за пренасочување за пакетите што минуваат низ рутерот. „Можам ли да го отворам SSH портот на рутерот?“ е прашање за влез за пакетите упатени кон самиот рутер. Правило за пропуштање напишано за пренасочен сообраќај не прави ништо за второто прашање, и тоа е најчестата причина зошто тунел што совршено пренесува сообраќај сепак ја одбива вашата административна сесија.

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

Прв слој: има ли маршрута до сопствената адреса на рутерот?

Започнете на клиентот и прашајте го јадрото каде ќе оди пакетот. На Linux ip route get 10.6.0.1 ги печати избраната маршрута, излезниот интерфејс и изворната адреса. Ако пријави стандардна маршрута кон вашиот давател, пакетот никогаш не влегува во тунелот, и ниедно правило на рутерот не може да го спаси.

Страната на тунелот има своја верзија на прашањето. WireGuard ги третира AllowedIPs како табела за криптоклучно насочување: на секој крај објавува кои изворни адреси смее да ги користи партнерот и кои одредишта се праќаат кон тој партнер. Ако записот на клиентот не ја вклучува тунелската адреса на рутерот, клиентот нема маршрута до неа. Ако записот на серверот за тој клиент не ја покрива тунелската адреса на клиентот, серверот го отфрла пакетот пред воопшто да погледне правило на огнениот ѕид.

Потврдете ја точната адреса до која очекувате да стигнете пред да ја дебагирате политиката. Застарениот DNS запис или кешираниот запис за сосед од пред промената ве води кон адреса што рутерот никогаш не ја поседувал.

Втор слој: влезната политика, не политиката за пренасочување

Огнените ѕидови ги оценуваат правилата на интерфејсот каде што пристигнува пакетот. На pfSense и OPNsense, јазичето на интерфејсот и редоследот на правилата одлучуваат дали сообраќајот кон сопствените услуги на огнениот ѕид е дозволен; правило што ги пушта LAN клиентите на интернет не е правило што му дозволува на тунелски партнер да го отвори веб-интерфејсот. На OpenWrt со firewall4 секоја зона носи влезна политика, option input 'ACCEPT' или 'REJECT', а тунелски интерфејс во зона со влез REJECT ќе одбива административни врски, додека сепак го пренесува сообраќајот ако пренасочувањето е дозволено.

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Трет слој: слуша ли нешто на таа адреса?

Услугата може да работи и сепак да е недостапна затоа што се врзала за една адреса. uhttpd на OpenWrt држи експлицитни записи за слушање во /etc/config/uhttpd, на пример list listen_http '0.0.0.0:80'; изградба што се врзува само за LAN адресата не прифаќа ништо на тунелската адреса, а производите што изложуваат поставка за интерфејс за слушање се однесуваат исто. Командите за слушање погоре одговараат на ова директно.

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

VPN интерфејсот е граница, не пат за враќање

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

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

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

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

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

Запишете четири работи пред првата промена: како ќе стигнете до уредот ако тунелот умре, на пример сериска конзола, конзола на давателот или машина во LAN; каде се извезува тековната конфигурација; кое единствено правило или маршрута ќе го смените; и како точно ќе го вратите тој елемент. На OpenWrt sysupgrade -b /tmp/backup.tar.gz ја фаќа конфигурацијата, а промените остануваат во исчекување до uci commit, што ви дава евтино враќање ако забележите навреме. pfSense води историја на конфигурација, а AutoConfigBackup помага само ако веќе бил вклучен. Ако рутерот работи со множество правила fail-closed, потврдете дека планираниот пат за одржување не е внатре во сообраќајот што го блокира тоа правило, и запомнете дека рестартирањето повторно ги применува трајните правила наместо да ги брише.

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

Брза проверка пред да заминете:

  • Дали стигнувате до рутерот од извор што не зависи од правилото што штотуку го уредивте?
  • Дали влезната политика на тунелскиот интерфејс дозволува само изворот на администраторот?
  • Дали административната услуга е врзана за адреса што постои на тунелот?
  • Дали тестиравте еден одбиен партнер и една нова сесија?
  • Дали површината за WAN администрација е се уште затворена?

Поврзани статии