La morta ŝaltilo blokas la VPN-servilon antaŭ ol ajna trafiko fluas
Kiun etapon morta ŝaltilo blokas: serĉo de finpunkto, ekstera itinero, revena vojo kaj eksdataj kunularaj esceptoj — kun nombriloj anstataŭ konjektoj.
Mortaj ŝaltiloj malsukcesas en direkto, kiun homoj ne atendas: ili estas konstruitaj por bloki trafikon dum la tunelo estas malsupre, kaj la pakaĵoj, kiuj konstruas la tunelon, mem estas trafiko. Tio estas la tuta cimo. Regularo, kiu forĵetas ĉion, kio ne eliras tra la tunelo, ankaŭ forĵetas la manpremon, kiu levus ĝin, do la kliento reprovas en buklo, kaj la eraro apartenas al tiu etapo, kiu estas kontrolata unue. Antaŭ ol vi plilarĝigos fajroŝirmilon, eltrovu, kiun el tri etapoj oni malakceptas: la nomserĉon, la eksteran pakaĵon al la kunulo, aŭ la respondon, kiu revenas.
Kiel la tunelo kaj ĝia propra transporto dependas unu de la alia
Legu VPN-klienton kiel du retajn statojn, kiuj dividas unu ingan vojon. Antaŭ ol la tunelo ekzistas, la kliento malfermas ingon sur la fizika adaptilo kaj sendas ĉifritajn kadrojn al la adreso kaj pordo de la kunulo. Nur post kiam tiu interŝanĝo sukcesas, ĝi kreas la tunelan aparaton kaj instalas itinerojn. Morta ŝaltilo estas politiko pri la dua stato, skribita tiel vaste, ke ĝi validas por ambaŭ.
Reguloj bazitaj sur interfaco estas la kutima formo: akceptu tion, kio eliras tra tun0 aŭ wg0, forĵetu la reston de la elira vojo. Tiu formulado ne povas escepti la propran konekton de la kliento al la servilo, do ĝusta efektivigo aldonas tiun escepton eksplicite, kaj vi same faras, kiam vi skribas regulojn permane. Reguloj por apartaj aplikaĵoj en Windows kaj macOS evitas parton de tio per kongruigo de procezo anstataŭ interfaco, sed la procezo tamen devas eliri antaŭ ol la tunelo ekzistas.
Tri etapoj, en la ordo, en kiu ili okazas
La unua etapo estas solvado. Kiam la profilo konservas gastigan nomon anstataŭ laŭvortan adreson, la kliento bezonas DNS-respondon antaŭ ol ĝi povas sendi ion ajn. Profilo, kiu direktas DNS al la solvilo de la tunelo, kreas sakstraton: la solvilo estas atingebla nur tra la tunelo, kiun la serĉo devus ebligi. Solvi ekster la tunelo, aŭ fiksi la finpunkton al adreso, forigas la dubecon.
La dua etapo estas la ekstera pakaĵo, kiu devas travivi unue la itinan administradon kaj poste la fajroŝirmilon, ĝuste en tiu ordo. wireguard-tools prizorgas la itinan duonon de tio por WireGuard per markado de siaj propraj pakaĵoj kaj aldono de politika regulo, por ke ili preterpasu la defaŭltan itinon, kiun ĝi ĵus instalas; la manpaĝo de wg-quick priskribas tiun regulon kaj la tabelon, kiun ĝi uzas. Rekonstruu tiun itinaron permane, aŭ lasu duan ilon reskribi la regulojn, kaj la markitaj pakaĵoj povas esti resenditaj en la tunelon, kiun ili devas establi.
La tria etapo estas la revena vojo. Manpremo sen respondo ne estas pruvo de elira forĵeto; ĝi egale kongruas kun enira regulo de la servilo aŭ NAT-aparato, kiu forgesis la mapadon. Apartigu tion antaŭ ol tuŝi la klienton.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Klientoj registras la simptomon, kiun ili detektas, ne la etapon, kiu fiaskis, do la tabelo kutime pli rapidas ol la protokolo.
Nombriloj decidas pli rapide ol protokoloj
En Linux, nft list ruleset aŭ iptables -vnL OUTPUT presas pakaĵan nombrilon por ĉiu regulo. Konektu unufoje, lasu ĝin fiaski, poste relegu la nombrilojn. Regulo, kies nombrilo moviĝis, estas regulo, kiun la manpremo trafis; se nenie io moviĝis, la pakaĵo neniam atingis la fajroŝirmilon. Mi vidis regularon forĵeti sian propran manpremon, kaj nur la nombriloj diris tion.
Por distingi neniam atingis la fajroŝirmilon de neniam forlasis la gastigon, observu la interfacon mem. ip -s link show dev wlan0 raportas senditajn pakaĵojn, kaj tcpdump -ni wlan0 udp port 51820 montras la kadrojn. Se ĝi restas ebena dum la kliento reprovas, la difekto estas super netfilter: mankas kunula itinero, politika regulo montras en aparaton, kiu ankoraŭ ne ekzistas, aŭ inga eraro, kiun la kliento englutas.
Testu esceptojn kontraŭ dokumentaraj adresoj kiel 203.0.113.10, por ke eraro ne povu sondi la gastigon de iu alia.
Eksdata finpunkta escepto legeblas kiel servila paneo
La plej trompa versio aperas post kiam la kunula adreso ŝanĝiĝis: servo de dinamikaj adresoj movis ĝin, la gastigo estis rekonstruita, aŭ la elira adreso de via reto diferencas. La escepto ankoraŭ nomas la malnovan adreson, do pakaĵoj al la nova trafas la forĵetan regulon. La sama agordo funkciis hieraŭ, kaj tial homoj komencas per diagnozado de la servilo.
Gastiga nomo ene de fajroŝirma regulo ne savas vin. En nftables la nomo solviĝas, kiam la regularo ŝargiĝas, do ĝi fiksas tiun adreson, kiu ekzistis en tiu momento, kaj eksdataiĝas kiel laŭvorta. La daŭra solvo estas ĝisdatigi la escepton, kiam la finpunkto ŝanĝiĝas, kaj teni ĝin mallarĝa: unu kunula adreso, unu transporta pordo. Intervalo sufiĉe larĝa por travivi adresan ŝanĝon ankaŭ sufiĉe larĝas por lasi nerilatan trafikon eliri.
Kiam la morta ŝaltilo funkcias sur la servila gastigo
La sama dependeco ekzistas ĉe la alia fino, kaj tie estas pli facile preteratenti ĝin. Se la maŝino, kiu funkcias kiel via VPN-servilo, ankaŭ rulas labortablan klienton kun morta ŝaltilo, aŭ fajroŝirman profilon kopiitan de tekkomputilo, ĝiaj forĵetaj reguloj validas por la servo, kiu finas la tunelojn. Respondoj al klienta manpremo estas forĵetataj, do ĉiu kliento malsukcesas konektiĝi, dum la servilo aspektas sana kaj ĝia tunela interfaco sidas neuzata.
Tiu gastigo bezonas tri mallarĝajn akceptojn antaŭ la forĵeto: la aŭskultan pordon sur la fizika interfaco, la tunelan interfacon por malĉifrita trafiko, kaj plusendadon de la tunelo al tio, kion la klientoj devas atingi. Legu la instalitan aron per nft list ruleset, iptables -S, aŭ pfctl -sr , antaŭ ol ŝanĝi ion ajn, kaj memoru, ke konservita regularo postvivas restartigon, do eraro tie postvivas la procezon, kiu faris ĝin.
Ripara ordo, kiu tenas la maŝinon fermita
Laboru eksteren de la profilo. Legu la kunulan adreson kaj pordon, kiujn la kliento uzas, konfirmu, ke la gastiga nomo solviĝas sen la tunelo, poste aldonu unu escepton por tiu adreso kaj pordo nur sur la fizika adaptilo. Rekonektiĝu kaj observu la sendan nombrilon; finita manpremo estas la signalo, ke la dua etapo estas riparita.
Lasu la reston de la forĵeta politiko en loko dum vi testas. Sendanĝera kontrolo estas provi konekton al nerilata dokumentara adreso kaj konfirmi, ke ĝi ankoraŭ tempolimas, kio montras, ke la morta ŝaltilo funkcias, ne ke ĝi estas malŝaltita. Streĉu la escepton, kiam la tunelo stabiliĝos, kaj ne lasu daŭran permeson por ĉio por la klienta programo nur ĉar ĝi oportunas.
Se la tunelo leviĝas kaj la aplikaĵo ankoraŭ fiaskas, la restantaj etapoj ne estas ĉi tiu: dividita DNS, MTU kaj itina administrado por apartaj aplikaĵoj ĉiu produktas konektitan tunelon kun rompita trafiko, kaj ĉiu havas alian unuan kontrolon.