UFW го исфрла DNS серверот на VPN штом тунелот се подигне
Политиката на стандардно одбивање на UFW го покрива и интерфејсот на тунелот. Подредете го сообраќајот по насока, дозволете го турнатиот resolver на tun0 и потоа отворете ја надворешната патека.
Имињата престануваат да се решаваат во моментот кога VPN се поврзува, додека ping до јавна адреса се уште одговара и статусот на огнениот ѕид не покажува ништо што изгледа погрешно. Во политиката ништо не се промени; се промени тоа што се појави нов интерфејс, а стандардното одбивање го покрива уште од првиот пакет. UFW одлучува по насока и интерфејс, затоа правило напишано за безжичната врска не кажува ништо за сообраќајот што излегува од тунелот. Поправката е грст тесни правила применети во определен ред.
Симптомот се појавува само откако тунелот ќе се подигне
Политиката на стандардно одбивање го прави точно она што ѝ е кажано: сето она што нема соодветно правило се одбива, на секој интерфејс што постои. Тунелот не постоеше кога се пишуваа правилата, затоа ниту едно од нив не може да го фати, а одбивањето што отсекогаш било таму сега се однесува на решавање имиња. Директниот сообраќај до буквална адреса се уште може да работи кога го покрива поширока дозвола, и затоа ping до јавен resolver успева, додека барањето име не успева. Празнината е правило за интерфејс што политиката никогаш не го видела.
Тоа исто така објаснува зошто дефектот чисто се превртува: спушти го тунелот и имињата повторно се решаваат, бидејќи барањето се враќа на интерфејс што има правила. Политика што не успева само додека тунелот е подигнат не е DNS проблем, а дотерувањето на самиот resolver овде губи најмногу време. Прочитајте ја листата на интерфејси пред да ја прочитате конфигурацијата на resolver.
Три насоки, три различни множества правила
Една сесија допира правила во повеќе од една насока, а тунелот додава втор интерфејс на речиси секоја од нив. Ако прво го подредите сообраќајот по насока и интерфејс, остатокот станува механички, бидејќи секој ред подолу бара свое правило на своето место. Примерите користат tun0 и базен од 10.8.0.0/24, затоа заменете ги имињата и опсезите со оние од сопствениот излез на клиентот.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Два реда често се мешаат бидејќи и двата го спомнуваат тунелот. Правилото за resolver дозволува сообраќај што клиентот го испраќа во тунелот, додека правилото за SSH дозволува сообраќај што серверот го прима од него; тие живеат на различни машини и не успеваат независно. Редот што најчесто се заборава е вториот, бидејќи клиентот воопшто не може да го изгради тунелот додека неговиот сообраќај до јавната адреса на серверот не биде дозволен. Работете од горе надолу и секој дефект има една веројатна причина.
Турнатиот resolver бара свое правило
Дали тунелот носи DNS зависи од тоа што го испраќа серверот. Сервер што турка опција за resolver инсталира приватна адреса во конфигурацијата на клиентот, и таа адреса е рутирачка само низ тунелот. Ако серверот не турка ништо, клиентот го задржува resolver што веќе го имал и правилата подолу немаат што да дозволат. Проверете ја турнатата состојба и тековниот резултат од барањето пред да напишете нешто:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedИзлезот од статусот го именува resolver што се користи и врската на која е врзан, а барањето рута зад него покажува кој интерфејс би пренел барање до таа адреса. Кога resolver седи на друга врска, проблемот е порано од огнениот ѕид и ниту едно правило нема да помогне. Кога двете се согласуваат за тунелот, потребни се две правила, бидејќи UDP носи повеќето барања, а TCP презема кога одговорот е скратен. Запишете ги двете вредности, бидејќи токму нив правилата ќе ги именуваат:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Отворете ја надворешната патека пред внатрешната
Клиентот мора да ја достигне јавната адреса на серверот пред да постои тунел, затоа правилото за тоа седи на физичката врска и мора да биде на место прво. Политика што го дозволува resolver, но го заборава серверот, го остава клиентот целосно неспособен да го изгради тунелот, а тој симптом обично се припишува на kill switch. Потоа дозволете ги услугите што навистина ги сакавте низ тунелот, едно тесно правило по едно, наместо да го отворите интерфејсот целосно. Тесните правила се причината зошто одбивањето може да остане на место.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Редот е важен додека тестирате, бидејќи првото правило е она што воопшто му дозволува на тунелот да се подигне. Додадете го, поврзете се и потврдете дека тунелот е подигнат пред да го додадете правилото за услугата, бидејќи правењето и двете одеднаш значи дека дефектот не ви кажува ништо за тоа која половина е погрешна. Заменете ја адресата од документацијата погоре со крајната точка за која клиентот е конфигуриран.
Завршете ја клиентската страна со намерно исклучување. Одбивањето треба се уште да го одбива сообраќајот што намерно сте го исклучиле, бидејќи resolver што одговара додека тунелот е подигнат покрива само половина од политика што одбива при сомнеж.
Клиент што се поврзува се уште не е примен
Серверот има своја насока што треба да ја земе предвид, а клиент што го завршува ракувањето се уште не достигнува ништо што работи на серверот додека серверот не го прими. Правилото за јавниот слушател само дозволува тунелот да постои; тоа не го пушта сообраќајот на тунелот внатре. На серверот тоа се две правила плус една проверка дека услугата навистина слуша:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Базенот во правилото мора да биде еднаков на опсегот што серверот го доделува, а бројот на тунелот мора да одговара на оној што серверот го создал, бидејќи правило за друг интерфејс е неразлично од никакво правило. limit е намерно за административен порт, бидејќи ограничува повторени врски наместо да ги прима без ограничување. Проверката на слушателот одделува затворен порт од отфрлен пакет, кои од клиентот изгледаат исто. Ни нумерираните правила не се целата слика: before правилата на UFW и секој рачно напишан nftables ред се совпаѓаат порано и се уште можат да одбијат пакет што листата изгледа дека го дозволува.