Домашният VPN сървър е недостъпен: проследете веригата NAT

Сървърът отговаря в LAN, правилото за пренасочване на порт изглежда правилно, а външен клиент все още не може да се свърже. Преминаването през една граница наведнъж е по-бързо от четвърто редактиране на правилото, защото всяка граница оставя свои доказателства: страницата WAN на рутера, преводът на доставчика и слушателят на хоста. Започнете от административната страница, която вече имате отворена, и завършете с тест от мрежа, която не контролирате. Записвайте всеки резултат в движение, защото последователността е диагностиката, а запомнено число не е доказателство. Ако ви трябва само изходящ тунел, преводът не е вашият проблем: блокира се само непоисканият входящ трафик.

Започнете от WAN страницата на рутера

Влезте в рутера и четете страницата със състоянието, а не списъка с пренасочвания на портове. Отбележете WAN адреса, интерфейса, към който принадлежи, и дали типът на връзката е DHCP, PPPoE или нещо, което доставчикът предоставя. След това сравнете този адрес с това, което съобщава външна услуга, като използвате телефон с мобилни данни, за да не се връща наблюдението през същия рутер. Двете числа отговарят на различни въпроси и сравняването им е целият смисъл на тази стъпка.

WAN адрес, който се различава от наблюдавания публичен адрес, означава, че поне един преводач стои над рутера. Това още не е неизправност, защото много доставчици превеждат по проект и услугата все още работи. Ако двете съвпадат, рутерът вероятно притежава адреса и проблемът се е преместил във вашата мрежа. Във всеки случай запишете двойката с датата, защото доставчиците преразпределят адреси и сравнение с миналия месец е безполезно.

Минете един хоп нагоре

Стартирайте traceroute от самия рутер и прочетете първите няколко хопа. Повтарящи се публични адреси, първи хоп, който отговаря с частен адрес, или адрес в споделения диапазон 100.64.0.0/10 всичко това сочи към преводач нагоре. RFC 6598 определя този диапазон точно за такова разгръщане и затова да го видите в полето WAN е силен сигнал, а не любопитство. Два преводача по пътя правят следата по-малко очевидна, затова четете шаблона, а не един ред.

Някои доставчици показват зададения адрес само в клиентския портал, затова погледнете там, преди да заключите, че рутерът лъже. Адрес в портала, който съвпада с външното ви наблюдение, докато рутерът съобщава друго, е най-ясното доказателство за преводач нагоре. Запазете и двете страници в записа за промени, защото спорът кой притежава коя граница върви много по-бързо с две датирани снимки.

Потвърдете слушателя и пренасочването

Тест в LAN доказва, че услугата работи локално, и не доказва нищо за достъпността отвън. Много рутери отговарят на собственото си правило за пренасочване отвътре, така че тест с обратна връзка минава, докато външният път остава затворен. Потвърдете, че демонът е вързан към адреса и порта, които смятате, и след това тествайте отвън. Всичко по-долу е само за четене.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Ако външният тест покаже, че до рутера не пристига пакет, отпадането е станало нагоре и никое локално правило няма да го поправи. Ако пакетите пристигат и нищо не отговаря, следващата граница е слушателят или защитната стена на хоста. Прихващането на пакети на хоста решава кой от двамата гледате и отнема по-малко време от още един кръг догадки за правилата. Дръжте слушателя и транспорта му непроменени, докато сравнявате, иначе следващият тест отговаря на друг въпрос.

Променете топологията, не същото правило

Когато преводачът принадлежи на доставчика, поправката е друг път, а не още едно пренасочване. Малък VPS с публичен адрес, свързан с изходящ тунел от домашната страна, поставя достъпна крайна точка пред услугата. Публичният адрес, предоставен от доставчика, е по-прост където съществува и обикновено по-евтин от поддържането на машина. IPv6 премахва превода напълно, при условие че клиентската мрежа, DNS записите и политиката на защитната стена го поддържат.

Динамичен DNS обновява само име; той не създава достъпност и насочването му към споделен адрес изпраща клиентите към шлюз на доставчика, който ползват и други абонати. Тази повреда изглежда точно като мъртъв сървър и затова записът от предишните стъпки е важен. Отбележете към кой адрес се е развързало името, когато тестът се провали, и пазете отговора заедно с резултата от теста.

Пренапишете плана около границата, която контролирате: слушателят, тунелът и маршрутите. Дръжте старото пренасочване на място само докато то все още описва нещо вярно, защото правило, което вече не отговаря на топологията, е по-лошо от липса на правило. Запишете кой слой всъщност е блокирал и какви доказателства го показаха. Иначе следващият човек, който отвори административната страница, повтаря всяка стъпка от този път от началото.