Răspunsul pleacă prin LAN, nu prin tunel: de ce și cum

Un serviciu publicat printr-o poartă funcționează din cea mai mare parte a internetului și eșuează dintr-un birou. Cineva verifică tunelul, vede cererea sosind și concluzionează că răspunsul trebuie să urmeze același drum înapoi. Linux nu funcționează așa, iar nicio inspecție a tunelului nu va schimba răspunsul. Răspunsul este rutat după destinație, iar acel singur apelant care eșuează se află într-o subrețea pe care gazda o atinge deja direct.

Ce decide de fapt un pachet de ieșire

Kernelul caută o rută pentru destinația pachetului, consultând regulile de politică în ordinea priorității și apoi tabela pe care o selectează o regulă potrivită. Interfața prin care a sosit un pachet nu joacă niciun rol, dacă nu a fost scrisă o regulă sau un marcaj pentru a o face relevantă. Este un fapt de rutare al acestei gazde, nu o defecțiune a tunelului.

O cerere primită prin tunel poate deci produce un răspuns care pleacă prin interfața fizică, iar fluxul devine unidirecțional fără ca vreun dispozitiv să raporteze o eroare. Verificați ambele direcții înainte de a trage o concluzie despre tunel. Un răspuns care pleacă în direcția greșită dispare din contoarele tunelului, de aceea cele două capete nu sunt de acord dacă s-a trimis ceva. Observați care contor s-a mișcat înainte de a atinge o regulă.

De ce câștigă subrețeaua locală

O gazdă cu o adresă într-o rețea locală are o rută conectată pentru acel prefix în tabela principală, iar o rută conectată este o potrivire directă. Când apelantul vine din aceeași subrețea, căutarea găsește legătura locală înainte ca tunelul să fie luat în considerare.

Asimetria este cea care face diagnosticul confuz. Apelanții din internetul mai larg funcționează pentru că nu se potrivesc cu nicio rută locală, în timp ce singurul apelant care împarte prefixul biroului eșuează, iar acesta este exact apelantul cu care cineva testează.

Acoperirea partenerilor nu este același lucru cu rutele instalate

Pe partea de tunel, intervalele permise ale unui partener descriu ce poate fi trimis în tunel și ce surse sunt acceptate din el. Nu spun nimic despre unde va trimite tabela de rutare locală un pachet.

Dacă instrumentul de tunel instalează o rută implicită pe gazdă, poate trage trafic nelegat în tunel ca daună colaterală. Acolo unde o regulă de politică ar trebui să dețină decizia, opțiunea de instalare a rutelor a instrumentului există exact pentru a împiedica acest lucru, iar adresele, cheile și setările punctului final rămân exact așa cum erau. O rută implicită adăugată pentru comoditate este o modalitate obișnuită prin care o gazdă își pierde propria rețea locală.

Alegeți tabela după adresa sursă

O regulă bazată pe sursă trimite răspunsurile de la adresa serviciului într-o tabelă privată a cărei valoare implicită este tunelul, în timp ce tot restul continuă să folosească tabela principală. Alegeți numere de tabelă și de prioritate nefolosite local și citiți regulile existente înainte de a introduce ceva. Citiți regulile active, nu un fișier salvat, pentru că cele două pot diferi după o repornire.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Ultima linie face ca o rută lipsă să eșueze vizibil în loc să revină la legătura locală. Sursa trebuie să fie într-adevăr atribuită gazdei, iar căutările locale și principale obișnuite trebuie să rămână în pozițiile anterioare. Regula alege o tabelă după sursă; nu compară lungimile prefixelor între tabele.

Confirmați calea, apoi serviciul

Întrebați kernelul ce ar face în loc să deduceți dintr-o captură, folosind adresa serviciului ca selector de sursă. Un răspuns corect aici economisește o urmărire completă a pachetelor.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Ieșirea ar trebui să numească tunelul. Apoi testați o sursă pe care nu ați atins-o și confirmați că folosește în continuare legătura locală, astfel încât modificarea a rămas limitată la o singură adresă. Un selector mai larg nu ar dovedi nimic despre plângerea originală.

Ce nu repară acest lucru

Lăsați redirecționarea, regulile de firewall și comportamentul ICMPv6 pe poartă așa cum erau, pentru că o rută de sursă nu înlocuiește niciuna dintre ele. Un mesaj Packet Too Big lipsă încă rupe răspunsurile mari, indiferent ce tabelă a câștigat căutarea. Remediați asta înainte de a adăuga reguli de rutare, altfel simptomul va supraviețui modificării.

Confirmați modelul de publicare înainte de a aplica orice din acestea. Un proxy invers care își deschide propria conexiune de backend își prezintă propria sursă și nu păstrează apelantul, așa că această defecțiune nu poate apărea în acel design. Aplicarea regulii acolo ar adăuga o excepție de rutare care nu rezolvă nimic și ascunde cauza reală.

În final, scrieți numerele regulilor și tabela în gestionarea configurației gazdei. O regulă de politică adăugată manual dispare la următoarea reconstrucție, iar apelantul din birou revine cu aceeași plângere.