Која врска одговара: рутирачки домени за DNS на split-tunnel VPN

Задржете го обичното прелистување на локалната врска, додека имињата на компанијата се решаваат преку DNS серверот што го обезбедува тунелот. Исклучувањето на стандардната рута на VPN ви ја дава првата половина, а втората останува неизградена. Следат поставката што недостасува, интерпункцијата што го менува нејзиното значење и единствената команда што покажува која врска навистина одговори. Низ целиот текст се претпоставуваат NetworkManager и systemd-resolved, бидејќи токму тој пар е местото каде што обично започнува забуната.

Прв чекор: одвојте ја рутата од решавачот

ipv4.never-default одговара на рутирачко прашање и спречува NetworkManager да ја инсталира оваа врска како пат за целиот IPv4 сообраќај. DNS рутирачки домен одговара на друго прашање: кои именски сервери на која врска добиваат барање за соодветен суфикс. Ниту едно не го подразбира другото, а профилот може со години да го носи едното додека другото недостасува. Само рута значи дека тунелот ги носи подмрежите на компанијата и неговиот решавач одговара на имињата на компанијата, а сето друго останува на мир.

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

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

Претпоставете дека врската се вика corp-vpn, суфиксот на компанијата е internal.example, а решавачот на тунелот е веќе достапен. Прво прочитајте ги тековните вредности, бидејќи командите подолу менуваат својства што може веќе да имаат записи.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

Почетна тилда означува домен само за рутирање, така што соодветните барања одат до серверите на оваа врска и суфиксот не се додава на кратките имиња. Отстранете ја тилдата и истиот текст станува и суфикс за пребарување, што е различен исход што луѓето ретко го сакаат. Двете поставки погоре се IPv4, така што профилот со двоен стек бара ipv6.never-default и истиот рутирачки домен во ipv6.dns-search, инаку страната IPv6 продолжува да ја користи стандардната рута и внатрешните имиња таму паѓаат.

Трет чекор: прашајте го resolvectl која врска одговори

Стартувајте resolvectl status и прочитајте ги DNS серверите и домените на секоја врска, потоа стартувајте resolvectl query host.internal.example против вистинско внатрешно име што смеете да го прашате. Втората команда е единствениот директен доказ дека рутирачкиот домен ја работи својата работа, бидејќи таа ја именува врската што одговори. Самиот список на статус ја докажува конфигурацијата; барањето го докажува решавањето.

systemd-resolved го избира најдобро соодветниот рутирачки домен, така што поспецифичен домен на друга врска сепак може да победи во трката. Ако барањето се врати од врска што не ја очекувавте, прочитајте ги списоците на домени пред да го допрете DNS серверот на VPN. Коренски домен ~. одговара на сето, и ако веќе постои, вашиот специфичен домен сепак победува за своите имиња додека врската одговара на многу повеќе отколку што побаравте. Отстранете го или стеснете го тој коренски запис кога намерата беше само имињата на компанијата.

Ако VPN врската воопшто не наведува DNS сервер, клиентот никогаш не регистрирал еден. Рутирачки домен без сервер зад него паѓа поинаку од домен што недостасува, затоа прво поправете ја регистрацијата.

Четврт чекор: кога името се решава, но услугата не

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

Промената во Samba што кружи покрај ова прашање се однесува на слојот за пристап, не на изборот на DNS. Нејзиното применување на дефект во решавање имиња е начинот на кој мал проблем добива втор.

Петти чекор: не го заменувајте решавачот за да поправите домен што недостасува

Советот што ја препишува датотеката на решавачот или инсталира друг менаџер на решавач решава друг проблем. Тоа се промени во системската интеграција со свои режими на дефект и ниту една не додава рутирачки домен што никогаш не бил конфигуриран. Утврдете кој компонент го поседува решавањето имиња на машината пред да го замените, бидејќи на работна површина со NetworkManager и systemd-resolved тоа власништво е веќе дефинирано. Борбата со тоа е начинот на кој работна поставка станува нешто што никој не може да го репродуцира.

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