Двоен NAT и вашиот VPN: клиентот работи, серверот не

Два рутери што преведуваат адреси ретко запираат излезен VPN клиент. Хостирање на сервер зад нив е потешко, особено кога надворешниот слој е NAT на оператор.

Вашиот рутер стои зад друг рутер, WAN адресата е приватна, а VPN клиентот сепак се поврзува. Оваа комбинација ги изненадува оние што очекуваат двојниот NAT да ги скрши тунелите, но токму излезните врски преводот ги обработува најдобро. Хостирање на VPN сервер зад истите два слоја е случајот што обично пропаѓа. Нацртајте ја насоката на врската пред да смените нешто.

Прво нацртајте ја насоката на врската

Отворете ја статусната страница на внатрешниот рутер и запишете ја неговата WAN адреса, потоа споредете ја со адресата што ви ја соопштува некоја јавна служба. Ако двете се разликуваат, меѓу вашиот рутер и интернетот стои барем еден преведувач. Ако WAN адресата паѓа во 100.64.0.0/10, надворешниот преведувач веројатно е на вашиот давател и вие не го контролирате. Овие два факти одлучуваат кој од подоцнежните чекори воопшто може да работи.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

Излезна насока: клиентот прашува, преведувачите мапираат

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

Дефектите што навистина се појавуваат обично се однесуваат на истекување на времето и поддршка на протоколи, а не на бројот на рутери. Тунел што паѓа по неколку минути тишина е мапирање што истекува, а keepalive е стандардниот одговор. IPsec има стандардни NAT-traversal екстензии, па тврдењето дека не може да премине преку превод е едноставно погрешно. Ако тунелот воопшто не се воспостави, погледнете ја крајната точка и акредитивите пред да ја обвините топологијата.

wg show
ping -c3 10.8.0.1

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

Влезна насока: проследувањето покрива само опрема што ја поседувате

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

Запрете ако надворешниот слој е на давателот и не проследува. Тогаш поддржаните одговори се друг метод на пристап или реле, а не уште едно правило од ваша страна.

Тестирајте една променлива истовремено

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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

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